NAB претерпевает третью “эволюцию” в том, как она защищает общедоступные облачные рабочие нагрузки, требуя, чтобы ее команды безопасности придумали еще более сильный набор защитных средств контроля.
Ранее в этом месяце банк сообщил ITnews, что он движется к программно-определяемому конечному состоянию своей ИТ-инфраструктуры, которая будет включать в себя несколько общедоступных облачных сервисов и локальное открытое оборудование.
Однако эта многооблачная архитектура требует нового подхода к элементам управления информационной безопасностью, которые защищают облачные рабочие нагрузки и данные NAB.
Эти усилия официально примут форму третьей эволюции внутренней справочной архитектуры и системы управления облачной безопасностью NAB.
Менеджер по стратегии и планированию безопасности Дэвид Уэст в прошлом месяце подробно рассмотрел эту структуру и то, как она развивалась с тех пор, как NAB впервые начала свое путешествие в публичное облако в 2012 году.
Выступая на недавнем саммите AWS в Сиднее, Уэст представил редкий, всесторонний взгляд на операции, стратегию и решения облачной безопасности крупной регулируемой организации.
“Поскольку нам пришлось поговорить с регулирующими органами о начале перемещения некоторых материальных рабочих нагрузок в облако, мы обнаружили, что такая структура действительно полезна с точки зрения очень четкого представления о том, как вы делаете безопасность”, — сказал он.
Уэст сказал, что когда NAB разместила свои фронтальные сайты- такие как nab.com.au — в AWS еще в 2012 году ее подход к облачной безопасности — и даже к облаку в целом — был “довольно тупиковым».”
— Если честно, нас немного затянуло в облако,” сказал Уэст.
— Было много враждебности по отношению к облаку.
“Но шесть лет назад облако было другим зверем для безопасности, и некоторые из ключевых сервисов [облачной безопасности], на которые мы полагаемся сейчас, были недоступны. Платформа тоже была совсем другой.”
Уэст сказал, что служба безопасности идентифицировала риски, связанные с облаком, и “четко сформулировала контроль”, который затем передала командам разработчиков банка для реализации.
“Там, где мы закончили, у нас была очень ориентированная на конечную точку архитектура”,-сказал он.
“Мы поставили микросегментацию с группами безопасности, VPC [виртуальными частными облаками] и NACLs [списками контроля доступа к сети]; мы поставили основу некоторых наших ключевых элементов управления, включая ведение журнала и мониторинг, а также ролевое управление доступом с IAM на грубозернистый уровень; и мы внедрили 2FA для доступа к консоли.”
Вторая эволюция облачных средств управления безопасностью банка произошла в 2016 году, когда NAB начал переносить транзакционные рабочие нагрузки в AWS.
Это стало серьезным изменением для отдела безопасности НАБ, заставив его занять более активную позицию.
“Мы поняли, как команда безопасности, что нам действительно нужно наклониться”, — сказал Уэст.
— Это облако никуда не делось, и нам действительно пришлось сильно наклониться.”
Уэст сказал, что вторая эволюция характеризовалась предоставлением некоторых “ключевых базовых средств контроля безопасности”, чтобы помочь банку расшириться в облако.
“Мы поставили федеративную идентификацию, мы определяем роли управления идентификацией и доступом (IAM) и политики управления доступом на основе ролей (RBAC) на гораздо более детальный уровень, и мы делаем обнаружение изменений API, ища изменения и дрейф конфигурации в нашей среде, опрашивая API”,-сказал Уэст.
“Мы также [начали] стандартизировать наши сборки учетных записей и наши AMIs [Образы машин Amazon] в той мере, в какой это было необходимо. В 2016 году мы начали видеть гораздо больше счетов, чем в 2012 году, так что по мере масштабирования управлять ими становилось все труднее, что делало стандартизацию гораздо более важной.
“И мы шифровали все: [служба управления ключами AWS] KMS теперь была доступна, поэтому мы шифровали [данные] в состоянии покоя и в пути.”
Важно отметить, что вторая эволюция также привела к созданию специальной группы по операциям облачной безопасности в NAB впервые.
“Это команда, которая сосредоточена исключительно на облаке и управляет всеми элементами управления безопасностью как частью нашей структуры [cloud security reference architecture and control]”, — сказал Уэст.
Прошло два года, и теперь, когда банк твердо встал на путь мультиоблачной системы управления, в 2018 году система управления претерпевает новую эволюцию.
Мультиоблачный подход совпадает с другими ключевыми архитектурными решениями, включая более широкое внедрение микросервисов и API, а также “облачный” подход к новым приложениям.
“Для нас как практика безопасности это означает, что мы снова склоняемся еще дальше”, — сказал Уэст.
“Наша команда облачных операций безопасности теперь развивается, чтобы стать инженерной командой, а это означает, что вместо того, чтобы просто контролировать элементы управления в облаке, мы теперь пишем код, который является элементами управления безопасностью в облаке.
“Мы используем CI/CD для сборки-тестирования-развертывания этого кода так же, как это делают наши разработчики. Сейчас мы определяем политику IAM и пишем правила конфигурации; мы работаем над автоматизацией всего, вплоть до исправления и самовосстановления; и мы рассматриваем высокоуровневые сервисы Amazon, такие как Lambda, чтобы поддержать это, а также Macie и Guard Duty, а также в других областях.”
Уэст сказал, что оперативная группа использует DevSecOps — часто также называемый SecDevOps — для усиления своего подхода к защите облачных рабочих нагрузок и данных.
Эта эволюция в настоящее время идет полным ходом.
Больше не » блокиратор’
Уэст рассматривает итеративный подход банка к облачной безопасности как “воплощение” его более широкой стратегии корпоративной безопасности.
Он отметил, что это показывает эволюцию мышления вокруг облака, даже в рамках строго регулируемой отрасли.
Облако-это признанный компонент ИТ, который позволяет организациям ускорить процесс доставки новых продуктов и функций на рынок.
В этом контексте безопасность не может позволить себе рассматриваться в качестве “блокатора” изменений.
“Управление безопасностью не должно противоречить гибкости и инновациям. На самом деле мы считаем, что это должно обеспечить гибкость и инновации”, — сказал Уэст.
“Одним из ключей к нашей стратегии безопасности [более широкого предприятия] является обеспечение безопасности банка, обеспечение того, чтобы у нас были правильные средства защиты для защиты банка и реагирования на меняющийся ландшафт угроз. “Мы также сосредоточены на том, чтобы позволить банку работать быстрее и делать это безопасно и надежно.
“Наши команды разработчиков и технологов обеспечивают изменения со скоростью и ритмом, которые сильно отличаются от того, что было пару лет назад, и как практика безопасности мы больше не можем сказать «нет».
“Мы не можем быть блокираторами и остановить эту каденцию доставки, но нам нужно решить, как мы можем поддерживать скорость, с которой доставляются изменения, но делать это безопасно и надежно.”
В то время как облачные позы безопасности выигрывали от конкретных структур и средств контроля, Уэст отметил, что многие традиционные принципы безопасности все еще применяются в облачном мире.
“То, как вы решаете эти проблемы, будет отличаться от мира на преме”,-сказал он.
Он подчеркнул важность итеративного подхода к созданию возможностей облачной кибербезопасности, а также использования возможностей абстракции и автоматизации, предоставляемых облачными архитектурами.
Уэст сказал, что фокус облачной безопасности банка делится на три основные области: развертывание собственных облачных возможностей безопасности там, где это имеет смысл, обеспечение безопасности облачных рабочих нагрузок по умолчанию (“безопасность должна быть запечена, а не закреплена болтами”) и обеспечение того, чтобы управление облачной безопасностью было непрерывным, итеративным процессом.
“Управление облачной безопасностью-это не разовая, временная, установленная и забытая деятельность, а непрерывная итеративная деятельность, за которой мы должны следить и делать”, — сказал он.
Структура управления облачной безопасностью NAB основана на модели совместной ответственности AWS.
При этом AWS отвечает за безопасность облака, а заказчик — в данном случае NAB — за безопасность рабочих нагрузок и данных, работающих в облаке.
“Это означает, что AWS позаботится о том, чтобы гипервизор был отключен, в то время как вам нужно позаботиться о рабочих нагрузках, которые вы выполняете в AWS”, — сказал Уэст.
“Наша система управления-это многоуровневый подход. Снизу вверх мы потребляем все сертификаты, которые предоставляет AWS, будь то SOC2, ISO, NIST или что-то еще.
“Мы потребляем их, вводя в структуру cloud security alliance CAIQ [consensus assessments initiative questionnaire], чтобы дать нам базовое представление о рисках и контроле для всех наших облачных провайдеров — но в данном случае для AWS — и мы включаем это в наши внутренние процессы due diligence и управления рисками.”
Структура управления также включала в себя “атомарный” взгляд на каждую услугу AWS, которую потреблял банк.
“Будь то EC2, S3,EBS или CloudTrail, мы проводим оценку атомарного риска, рассматривая каждую из этих услуг, прежде чем сертифицировать их для производственного использования”, — сказал Уэст.
“Мы смотрим вниз по этой структуре, чтобы убедиться, что правильные сертификаты присущи этим новым сервисам — иногда сервисы опережают сертификаты, — но мы также смотрим вверх по стеку на нашу собственную среду управления, чтобы убедиться, что мы можем интегрировать эти сервисы в созданную нами среду управления.”
Верхний уровень структуры управления банка определяет области, в которых он несет ответственность за собственную безопасность в облаке.
“Наконец, последнее, но не менее важное, мы оборачиваем вокруг этого сквозную систему текущих операций и управления”, — сказал Уэст.
“У нас есть оперативная группа, которая очень тщательно следит за нашими рабочими нагрузками, гарантируя, что все средства контроля безопасности в нашей системе работают эффективно, и у нас также есть функция управления, которая занимается непрерывным непрерывным управлением поставщиками, обеспечением поставщиков и сертификацией услуг.”
