Платформа Azure Well-Architected Framework — это набор руководящих принципов, которые можно использовать для оценки решения с помощью основных принципов качества архитектуры:
- Оптимизация затрат
- Эффективность операционных процессов
- Уровень производительности
- Надежность
- Безопасность
В этой статье заканчивается эта серия. Ознакомьтесь с введением.
Это руководство, предоставленное в этой серии, включает принципы хорошо архитекторов во всех вариантах проектирования. В этой статье описаны варианты выбора. GitHub: реализация базового кластера Служба Azure Kubernetes (AKS) для регулируемых рабочих нагрузок демонстрирует эти принципы, как применимо.
Рабочие нагрузки PCI DSS 3.2.1 требуют строгого решения. Несмотря на то, что соответствие инфраструктуры требованиям PCI является критически важным, соответствие не останавливается на инфраструктуре размещения. Отсутствие решения вопросов качества, в частности безопасности, может поставить под угрозу соответствие требованиям. Хорошо спроектированные решения объединяют как инфраструктуру, так и перспективы рабочей нагрузки, чтобы достичь строгости, необходимой для достижения соответствующих результатов.
Безопасность
Следуйте основным рекомендациям, приведенным в принципах проектирования безопасности. Рекомендации по регулированию среды приведены в этих разделах.
Система управления
Реализация управления зависит от требований соответствия требованиям в PCI-DSS 3.2.1. Это влияет на технические элементы управления для поддержания сегментации, доступа к ресурсам, обнаружения уязвимостей и наиболее важной защиты данных клиентов.
Стратегия сегментации предприятия
Чтобы обеспечить полную изоляцию, рекомендуется развернуть регламентированную инфраструктуру в автономной подписке. Если у вас есть несколько подписок, необходимых для соответствия требованиям, рекомендуется группировать их в иерархии групп управления, которая применяет соответствующие политики Azure равномерно в область подписках. В рамках подписки примените связанные политики Azure на уровне подписки, чтобы записать широкие политики, которые должны применяться ко всем кластерам в среде данных карта заполнителей (CDE). Примените связанные политики Azure на уровне группы ресурсов для отслеживания политик, применяемых к конкретному экземпляру кластера. Эти политики создают основные ограждения целевой зоны.
Изоляция рабочей нагрузки PCI (в область) от других (вне область) рабочих нагрузок с точки зрения операций и подключения. Вы можете создать изоляцию, развернув отдельные кластеры. Кроме того, используйте стратегии сегментации для поддержания разделения. Например, кластеры используют отдельные пулы узлов, чтобы рабочие нагрузки никогда не совместно использовали виртуальную машину узла.
Применение политики
Принудительное применение элементов управления безопасностью, включив политики Azure. Например, в этой регламентированной архитектуре можно предотвратить неправильное настройку среды данных карта заполнителя. Вы можете применить политику Azure, которая не разрешает выделение общедоступных IP-адресов на узлах виртуальной машины. Такие выделения обнаруживаются и блокируются.
Сведения о политиках, которые можно включить для AKS, см. в Политика Azure встроенных определений для Служба Azure Kubernetes.
Azure предоставляет несколько встроенных политик для большинства служб. Просмотрите эти Политика Azure встроенные определения политик и примените их соответствующим образом.
Мониторинг соответствия требованиям
Необходимо систематически отслеживать и поддерживать соответствие требованиям. Проводятся регулярные аттестации на соответствие требованиям. Зная, соответствуют ли облачные ресурсы, вы сможете подготовиться к аттестации и аудиту.
Воспользуйтесь панелью мониторинга соответствия нормативным требованиям в Microsoft Defender для облака. Постоянно отслеживая состояние соответствия рабочей нагрузки, вы можете отслеживать состояние панели мониторинга.
Сетевая безопасность
В звездообразной топологии, наличие отдельных виртуальных сетей для каждой сущности обеспечивает базовую сегментацию в сетевом следе. Каждая сеть будет сегментирована в подсети.
Кластер AKS формирует ядро CDE. Он не должен быть доступен из общедоступных IP-адресов, и необходимо защитить подключение. Типичные потоки в CDE и вне него можно классифицировать как:
- Входящий трафик в кластер.
- Исходящий трафик из кластера.
- Трафик между модулями pod в кластере.
Для удовлетворения требований регулируемых сред кластер развертывается в качестве частного кластера. В этом режиме трафик к общедоступному Интернету ограничен. Даже взаимодействие с сервером API Kubernetes, управляемым AKS, является частным. Безопасность улучшается с помощью строгих сетевых элементов управления и правил брандмауэра IP-адресов.
- Группы безопасности сети (NSG) помогают защитить обмен данными между ресурсами в сети.
- Брандмауэр Azure фильтровать исходящий трафик между облачными ресурсами, Интернетом и локальной средой.
- Шлюз приложений Azure интегрирован с Azure Web Application Framework для фильтрации всего входящего трафика из Интернета, который Шлюз приложений Azure перехватывается.
- Kubernetes NetworkPolicy позволяет разрешить только определенные пути между модулями pod в кластере.
- Приватный канал Azure для подключения к другим службам Платформы Azure как услуга (PaaS), таким как Azure Key Vault и Реестр контейнеров Azure для операционных задач.
Процессы мониторинга выполняются, чтобы убедиться, что потоки трафика должны быть ожидаемыми, и что обнаружена и сообщается любая аномалия.
Дополнительные сведения о безопасности сети см. в разделе "Сегментация сети".
Безопасность данных
ДЛЯ PCI-DSS 3.2.1 требуется, чтобы все данные карта заполнителей (CHD) никогда не были ясны, независимо от того, является ли транзит или в хранилище.
Так как эта архитектура и реализация ориентированы на инфраструктуру, а не рабочую нагрузку, управление данными не демонстрируется. Ниже приведены некоторые хорошо спроектированные рекомендации.
Неактивные данные
Данные должны быть зашифрованы с помощью стандартных алгоритмов шифрования в отрасли.
- Не сохраняйте данные в среде карта заполнителей.
- Шифрование за пределами уровня хранилища.
- Записывайте только зашифрованные данные в носитель хранилища.
- Не сохраняйте ключи на уровне хранилища.
Все данные в служба хранилища Azure шифруются и расшифровываются с помощью строгой криптографии. Предпочтителен самоуправляемый ключ шифрования.
Если необходимо временно хранить данные, примените те же рекомендации к этим данным. Настоятельно рекомендуется включить функцию шифрования узлов AKS. Вы можете применить шифрование временных данных со встроенными политиками Azure.
При выборе технологии хранения изучите функции хранения. Убедитесь, что все данные будут безопасно удалены при истечении срока действия настроенного времени.
Стандарт также требует, чтобы конфиденциальные данные проверки подлинности (SAD) не хранятся. Убедитесь, что данные не предоставляются в журналах, именах файлов, кэше и других данных.
Передаваемые данные
Все связи с сущностями, взаимодействующими с CDE, должны быть через зашифрованные каналы.
- Только трафик HTTPS должен быть разрешен для передачи в CDE. В этой архитектуре Шлюз приложений Azure запрещает весь трафик через порт 80.
- Желательно не шифровать и расшифровывать данные за пределами CDE. Если вы это делаете, рассмотрите, что сущность является частью CDE.
- В CDE обеспечивает безопасный обмен данными между модулями pod с помощью MTLS. Вы можете реализовать сетку служб для этой цели.
- Разрешить только безопасные шифры и TLS 1.2 или более поздней версии.
Идентификация
Следуйте этим принципам безопасности при разработке политик доступа:
- Начните с политик нулевого доверия. При необходимости сделайте исключения.
- Предоставьте минимальным привилегиям достаточно, чтобы завершить задачу.
- Свести к минимуму постоянный доступ.
Управление доступом на основе ролей Kubernetes (RBAC) управляет разрешениями api Kubernetes. AKS поддерживает эти роли Kubernetes. AKS полностью интегрирован с идентификатором Microsoft Entra. Удостоверения Microsoft Entra можно назначить ролям, а также воспользоваться другими возможностями.
Доступ к нулю доверия
Kubernetes RBAC, Azure RBAC и службы Azure реализуют запретить все по умолчанию. Переопределите этот параметр с осторожностью, разрешая доступ только к тем сущностям, которым он нужен. Еще одной областью реализации нулевого доверия является отключение доступа SSH к узлам кластера.
Минимальные привилегии
Управляемые удостоверения можно использовать для ресурсов и модулей pod Azure, а также область их ожидаемым задачам. Например, Шлюз приложений Azure должны иметь разрешения на получение секретов (сертификатов TLS) из Azure Key Vault. У него не должно быть разрешений на изменение секретов.
Минимизация постоянного доступа
Свести к минимуму постоянный доступ с помощью JIT-членства в группе Microsoft Entra. Закрепите элемент управления с помощью политик условного доступа в идентификаторе Microsoft Entra. Этот параметр поддерживает множество вариантов использования, таких как многофакторная проверка подлинности, ограничение проверки подлинности на устройствах, управляемых клиентом Microsoft Entra, или блокировка нетипических попыток входа.
Управление секретами
Храните секреты, сертификаты, ключи и пароли за пределами CDE. Вы можете использовать собственные секреты Kubernetes или управляемое хранилище ключей, например Azure Key Vault. Использование управляемого хранилища поможет в задачах управления секретами, таких как смена ключей и продление сертификатов.
Убедитесь, что доступ к хранилищу ключей имеет баланс сетевых и элементов управления доступом. При включении управляемых удостоверений кластер должен пройти проверку подлинности в Key Vault, чтобы получить доступ. Кроме того, подключение к хранилищу ключей не должно быть через общедоступный Интернет. Используйте частную сеть, например Приватный канал.
Эффективность работы
Следуйте основным рекомендациям, приведенным в принципах операционного превосходства. Рекомендации по регулированию среды приведены в этих разделах.
Разделение ролей
Применение четкой сегрегации обязанностей для регулируемых сред является ключевым. Определение ролей и обязанностей зависит от потребностей рабочей нагрузки и взаимодействия с CDE. Например, может потребоваться роль оператора инфраструктуры или инженера надежности сайта (SRE) для операций, связанных с кластером и зависимыми службами. Роль отвечает за обеспечение безопасности, изоляции, развертывания и наблюдаемости. Формируйте эти определения и определите необходимые разрешения. Например, службы SREs имеют высокий уровень привилегий для доступа к кластеру, но требуют доступа на чтение к пространствам имен рабочей нагрузки.
Изоляция рабочих нагрузок
ДЛЯ PCI-DSS 3.2.1 требуется изоляция рабочей нагрузки PCI из других рабочих нагрузок с точки зрения операций. В этой реализации рабочие нагрузки в область и вне область сегментируются в двух отдельных пулах узлов пользователей. Разработчики приложений для область и разработчиков для рабочих нагрузок вне область могут иметь разные наборы разрешений. Кроме того, будут отдельные ворота качества. Например, код в область подлежит поддержанию соответствия и аттестации, в то время как не область код. Кроме того, необходимо иметь отдельные конвейеры сборки и процессы управления выпусками.
Операционные метаданные
Требование 12 стандарта PCI DSS 3.2.1 требует наличия сведений о инвентаризации рабочей нагрузки и документации по персоналу. Настоятельно рекомендуется использовать теги Azure, так как можно сгруппировать сведения о среде с ресурсами Azure, группами ресурсов и подписками.
Сведения о утвержденных решениях, входящих в инфраструктуру и рабочую нагрузку. Это включает в себя список образов виртуальных машин, баз данных и сторонних решений, которые вы можете перенести в CDE. Вы даже можете автоматизировать этот процесс, создав каталог служб. Он обеспечивает самостоятельное развертывание с помощью утвержденных решений в определенной конфигурации, которая соответствует текущим операциям платформы.
Наблюдаемость
Для выполнения требования 10 наблюдение в CDE имеет решающее значение для соответствия требованиям. Журналы действий предоставляют сведения об операциях, связанных с управлением учетными записями и секретами, управлением параметрами диагностики, управлением серверами и другими операциями доступа к ресурсам. Все журналы записываются с датой, временем, удостоверением и другими подробными сведениями. Сохраняйте журналы до года, настраивая политики хранения данных и архивирования в журналах Azure Monitor.
Убедитесь, что журналы доступны только ролям, которым они нужны. Log Analytics и Microsoft Sentinel поддерживают различные элементы управления доступом на основе ролей для управления доступом к следу аудита.
Ответ и исправление
Службы мониторинга Azure, Azure Monitor и Microsoft Defender для облака, могут создавать уведомления или оповещения при обнаружении аномальных действий. Эти оповещения включают сведения о контексте, такие как серьезность, состояние и время действия. По мере создания оповещений у вас есть стратегия исправления и ход выполнения проверки. Мы рекомендуем централизованно использовать данные в решении для управления безопасностью и событиями (SIEM), так как интеграция данных может обеспечить широкий контекст оповещений.
В представлении оповещений системы безопасности в Microsoft Defender для облака у вас есть доступ ко всем оповещениям, которые Microsoft Defender для облака обнаруживать ресурсы. Чтобы устранить проблему, необходимо выполнить триадж-процесс. Обратитесь к группе безопасности, чтобы понять, как соответствующие оповещения будут доступны владельцам рабочих нагрузок.
Уровень производительности
Следуйте основным рекомендациям, приведенным в принципах эффективности производительности. Рекомендации по регулированию среды приведены в этих разделах.
Масштабирование
Наблюдая, как среда настраивается на изменение требований, будет указывать ожидаемое поведение среды выполнения среды под высокой нагрузкой. Автомасштабирование ресурсов в рабочей нагрузке приведет к минимизации взаимодействия с человеком в CDE. Дополнительное преимущество безопасности сокращает область атаки в любое время. Вы можете максимизировать преимущество, используя ресурсы, поддерживающие подход масштабирования до нуля. Например, AKS поддерживает масштабирование пулов узлов пользователей до 0. Дополнительные сведения см. в разделе "Масштабирование пулов узлов пользователей до 0".
Секционирование
Секционирование является ключевым фактором эффективности производительности в регулируемых рабочих нагрузках. Наличие дискретных компонентов позволяет четко определить ответственность и помогает в точных элементах управления, таких как политики сети. Как и любая стратегия сегментации, секционирование изолирует компоненты и управляет воздействием радиуса взрыва на непредвиденные сбои или компрометацию системы.
Архитектура shared-nothing
Архитектура shared-nothing предназначена для удаления состязаний между совместно используемыми рабочими нагрузками. Кроме того, это стратегия удаления отдельных точек сбоя. В регулируемых средах компоненты должны быть изолированы логическими или физическими границами. Это соответствует архитектуре общего ничего, что приводит к преимуществам масштабируемости. Кроме того, он позволяет использовать соответствующие средства управления безопасностью и более жесткие возможности аудита различных компонентов.
Упрощенные платформы
Сложность рабочих нагрузок трудно документировать и проверять. Стремитесь к простоте из-за преимуществ производительности и простоты аудита нормативных требований. Оцените выбор, который имеет больше дыхание, чем требуется, потому что это увеличивает область атаки и потенциал для неправильного использования или неправильной настройки.
Надежность
Надежность регулируемых сред должна быть предсказуемой, чтобы их можно было последовательно объяснить для целей аудита. Следуйте основным рекомендациям, приведенным в принципах надежности. Рекомендации по регулированию среды приведены в этих разделах.
Целевые объекты восстановления и аварийное восстановление
Из-за конфиденциальности данных, обрабатываемых в регулируемых рабочих нагрузках, целевых объектов восстановления и целей точки восстановления (RPOS) критически важны для определения. Что такое допустимая потеря CHD? Усилия по восстановлению в CDE по-прежнему применяются к стандартным требованиям. Ожидайте сбоев и имеет четкий план восстановления для этих сбоев, которые соответствуют ролям, обязанностям и оправданным доступом к данным. Проблемы с динамическим сайтом не являются оправданием для отклонения от каких-либо правил. Это особенно важно в полной ситуации аварийного восстановления. Удаляйте документацию по аварийному восстановлению, которая соответствует требованиям и сводит к минимуму непредвиденный доступ CDE или CHD. После восстановления всегда просмотрите шаги процесса восстановления, чтобы убедиться, что не произошло неожиданного доступа. Документируйте бизнес-обоснование для этих экземпляров.
Восстановление
Добавление стратегий устойчивости и восстановления в архитектуру может предотвратить необходимость нерегламентированного доступа к CDE. Система должна быть в состоянии самостоятельно восстановиться в определенном RPO без необходимости прямого вмешательства человека. Таким образом, вы можете исключить ненужные воздействия CHD, даже для тех лиц, которые уполномочены иметь экстренный доступ. Процесс восстановления должен быть проверяемым.
Устранение рисков, связанных с безопасностью
Просмотрите риски безопасности, так как они могут быть источником простоя рабочей нагрузки и потери данных. Инвестиции в безопасность также влияют на надежность рабочей нагрузки.
Рабочие процессы
Надежность распространяется на все операционные процессы в CDE и рядом с ними. Хорошо определенные, автоматизированные и проверенные процессы для таких проблем, как создание образов и фактор управления коробкой переходов в хорошо спроектированное решение.
Оптимизация затрат
Следуйте основным рекомендациям, приведенным в принципах оптимизации затрат.
Из-за требований соответствия требованиям и строгих элементов управления безопасностью четкий компромисс является затратами. Рекомендуется установить начальные оценки с помощью калькулятора цен.
Ниже приведено высокоуровневое представление влияния на затраты основных ресурсов, которые использует эта архитектура.
Основными драйверами являются масштабируемые наборы виртуальных машин, составляющие пулы узлов и Брандмауэр Azure. Другим участник является Log Analytics. Существуют также добавочные затраты, связанные с Microsoft Defender для облака, в зависимости от вашего выбора планов.
Четкое понимание того, что представляет собой цену услуги. Azure отслеживает использование с лимитным использованием. Вот детализация Брандмауэр Azure для этой архитектуры.
Затраты, связанные с некоторыми ресурсами, такими как Брандмауэр Azure, могут распространяться между несколькими бизнес-единицами и (или) приложениями. Другим способом оптимизации затрат может быть размещение мультитенантного кластера в организации, максимизация плотности с разнообразием рабочей нагрузки. Мы не рекомендуем этот подход для регулируемых рабочих нагрузок. Всегда приоритеты соответствия и сегментации по сравнению с преимуществами затрат.
Чтобы сохранить в пределах ограничений бюджета, некоторые способы управления затратами позволяют настроить инфраструктуру Шлюз приложений Azure, задать количество экземпляров для автомасштабирования и сократить выходные данные журнала до тех пор, пока они по-прежнему соответствуют следу аудита, требуемому PCI-DSS 3.2.1. Всегда оценивать эти варианты в отношении компромиссов по другим аспектам проектирования, которые позволяют вам соответствовать вашему соглашению об уровне обслуживания. Например, вы по-прежнему можете масштабировать соответствующим образом для удовлетворения пиков трафика.
При создании групп ресурсов Azure примените теги, чтобы их можно было отслеживать по затратам. Используйте такие средства управления затратами, как Помощник по Azure и Управление затратами Azure для отслеживания и анализа затрат.
Рассмотрите возможность включения анализа затрат AKS для распределения затрат на инфраструктуру детализированного кластера определенными конструкциями Kubernetes.