Создание и проверка плана Azure PCI с использованием инфраструктуры в качестве кода (IaC) - безопасность, соответствие требованиям и конфиденциальность в нескольких облаках

1. Определение эталонной архитектуры (RA)
2. Определение инфраструктуры как кода (IaC)
3. Необходимость согласованности в работе в нескольких средах:
4. Обеспечение ценности в модели постепенного развития:
5. Сотрудничество между членами команды невозможно без IaC на основе управления исходным кодом:
6. Полный жизненный цикл разработки программного обеспечения был бы невозможен:
7. Невозможно задокументировать каждую отдельную конфигурацию и точки интеграции с самого начала:
8. Время, необходимое для поддержания среды, было бы в днях:
9. Невозможно проверить:
10. Поддерживаемость является ограничением:

Этот блог представляет собой пример для разработчиков, инженеров по эксплуатации, архитекторов и других подобных ролей, чтобы ускорить создание своих приложений и облачной инфраструктуры с использованием IaC. И мы можем с гордостью заявить об этом, потому что наша родительская консалтинговая команда Avyan Consulting Corp ) сделал это и понял преимущества этого. Информация об общедоступной эталонной архитектуре доступна здесь - Azure Blueprint - решение для обработки платежей с поддержкой PCI DSS ,

В этом блоге не будут подробно рассказываться о решении, а будет рассказано о том, как были организованы команды, о продолжении совместной работы и об упрощенных процессах, которые привели к созданию решения из 3 разных часовых поясов. Раствор RA, который был наконец отправлен, показан ниже.

Определение эталонной архитектуры (RA)

Эталонная архитектура в области архитектуры программного обеспечения или архитектуры предприятия предоставляет шаблонное решение для архитектуры для конкретного домена. Он также предоставляет общий словарь для обсуждения реализаций, часто с целью подчеркнуть общность. Эталонная архитектура программного обеспечения - это архитектура программного обеспечения, где структуры и соответствующие элементы и отношения предоставляют шаблоны для конкретных архитектур в конкретной области или в семействе программных систем.

Определение инфраструктуры как кода (IaC)

Отрывок из Википедии о Инфраструктура как код -

Инфраструктура как код (IaC) - это процесс управления и обеспечения компьютерных центров обработки данных с помощью машиночитаемых файлов определений, а не физической конфигурации оборудования или интерактивных инструментов настройки. Как физическое оборудование, такое как серверы без поддержки, так и виртуальные машины и связанные с ними ресурсы конфигурации, называются «инфраструктурой», хотя они не имеют ничего общего с реальной инфраструктурой. Определения могут быть в системе контроля версий. Он может использовать сценарии или декларативные определения, а не ручные процессы, но этот термин чаще используется для продвижения декларативных подходов.

Инфраструктура как подходы кода продвигается для облачных вычислений, которые иногда продаются как инфраструктура как услуга (IaaS). IaC поддерживает IaaS, но его не следует путать.

Прежде чем мы поговорим о IaC, рассмотрим некоторые пункты высокого уровня, которые, по нашему мнению, были проблематичными, если бы IaC не была методологией, которой мы следовали.

Необходимость согласованности в работе в нескольких средах:

Один из первых принципов, которыми мы руководствовались, это то, что мы хотим быть последовательными, когда отправляем наш RA в среду наших клиентов. Наша команда работала над несколькими подписками Azure, и всю эту инфраструктуру нужно было превратить в подписку, к которой у нас не будет доступа. Способность повторения и последовательность были ограничениями дизайна для нас.

Обеспечение ценности в модели постепенного развития:

Мы следовали методологиям гибкой разработки, в которых добавочная стоимость достигается еженедельно или раз в две недели. Наши внутренние архитекторы и наши клиенты будут проверять и предоставлять нам отзывы почти еженедельно.

Сотрудничество между членами команды невозможно без IaC на основе управления исходным кодом:

Наш пилотный клиент и наши команды разработчиков были на 3 разных континентах. Нам нужен был способ постоянно поддерживать высокий уровень сотрудничества между членами команды, но все же преодолевать коммуникационные барьеры из-за множества географических регионов.

Полный жизненный цикл разработки программного обеспечения был бы невозможен:

Ежедневные проверки, ежедневное тестирование и ежедневная внутренняя обратная связь были заявленными целями с самого начала. Наши опытные клиенты также были вовлечены ежедневно. Нам нужно было убедиться, что SDLC выполняется, и он по-прежнему очень гибкий.

Невозможно задокументировать каждую отдельную конфигурацию и точки интеграции с самого начала:

Наши архитекторы и наши опытные клиенты столкнулись с трудностями при документировании всех точек интеграции и сквозных конфигураций. Нам нужен был способ хранения и управления конфигурациями и интеграцией с первого дня. Механизм контроля источников и методологии SDLC помогли нам найти ответы.

Время, необходимое для поддержания среды, было бы в днях:

На поддержание и настройку среды с более чем 15+ ресурсами Azure может потребоваться несколько дней, даже если будет предоставлена ​​надлежащая документация (и через некоторое время документация устареет). Мы хотели выдержать обстановку в течение нескольких часов.

Невозможно проверить:

После развертывания такой сложной среды мы хотели, чтобы наши пилотные клиенты могли проверить конфигурации для каждого ресурса. Нашим пилотным клиентам, командам архитекторов и внутренних операций требовался механизм, позволяющий проводить тесты и проверять их очень быстро. Шаблоны Azure ARM обеспечивают Idempotency, который очень помогает в достижении цели.

Поддерживаемость является ограничением:

Нашим пилотным клиентам было сложно сообщить о проблемах, с которыми они столкнулись во время развертывания. Открытый исходный код IaC дал возможность заинтересованным сторонам точно определить проблему, с которой они столкнулись, во многих случаях они могли поддержать себя (самообслуживание), исправив проблему и отправив нам запрос на извлечение информации (PR)

Все проблемы, перечисленные выше и более, будут решены с помощью IaC. IaC помог нам достичь согласованности независимо от среды, в которой они были развернуты. Это также позволило нам вносить постепенные изменения и дополнения в нашу существующую эталонную архитектуру благодаря ее идемпотентному характеру. Идемпотентный означает, что шаблоны могут быть развернуты снова и снова, не влияя на текущее состояние ресурсов. Это позволило нашим архитекторам избежать значительных усилий по исправлению ошибок или добавлению любой новой конфигурации в среду.

Внедрение системы управления исходным кодом, такой как GIT, для управления кодами помогло нам сотрудничать между людьми из разных регионов. Это не только позволило нам отслеживать версию кода, но и позволило нашей команде архитекторов и эксплуатационников одновременно работать с различными ресурсами и конфигурацией, что позволило нам сократить время на создание этой эталонной архитектуры.

Теперь, когда инфраструктура управляется как код, нам не нужно документировать каждую конфигурацию, а только шаги для развертывания этих кодов в конкретной среде. В связи с этим нашим архитекторам не пришлось подробно документировать конфигурацию, а наши клиенты Pilot были спасены, чтобы пройти длинные руководства, чтобы выдержать такие условия.

Наша команда поставила очень сложную эталонную архитектуру в сотрудничестве с несколькими командами, распределенными по 3 различным континентам, используя вышеупомянутые рекомендации и принципы. Наши механизмы проверки также автоматизированы, и правила проверки также были отправлены в наш продукт Cloudneeti, доступный на торговой площадке Azure.

Попробуйте cloudneeti отсюда

https://azuremarketplace.microsoft.com/en-us/marketplace/apps/cloudneeti.cloudneeti_enterpise?tab=Overview

[easy-tweet tweet = ”Построение #Azure #PCIDSS #Blueprint с использованием IaC” user = ”cloudneeti” hashtags = ”AzureBlueprint, Compliance, Azure, Security” template = ”dark”]

Похожие

Комментарии