Безопасность Azure для FinTech и SaaS: архитектура от границ доверия к доказательствам

Архитектура безопасности Azure — это не схема с названиями служб вокруг рабочей нагрузки. Это система решений о доверии: кто или что может действовать, с каким ресурсом и данными, при каких условиях; как это решение исполняется; какие доказательства оно оставляет; как организация ограничивает злоупотребление. В продуктах FinTech и SaaS последствия особенно ощутимы, ведь один запрос может пересечь идентичность клиента, авторизацию в его изолированной среде, движение средств, персональные данные, стороннего поставщика и регулируемую запись.

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

Начинайте с идентичностей людей и привилегированного доступа

Используйте Microsoft Entra ID как уровень управления, но стройте жизненный цикл идентичностей вокруг людей и риска. Разделяйте идентичности сотрудников, клиентов, служб и аварийного доступа. Там, где это уместно, объединяйте доступ сотрудников с корпоративным поставщиком идентичностей; для привилегированных ролей требуйте устойчивой к краже учётных данных аутентификации в соответствии с риском; осознанно применяйте Conditional Access и блокируйте устаревшие пути, обходящие современную защиту. Предоставляйте и отзывайте доступ по достоверным событиям найма, смены роли или завершения сотрудничества: ежеквартальный пересмотр не исправит ситуацию, когда учётная запись уволенного сотрудника остаётся активной.

Назначайте роли Azure на самом узком уровне, который можно поддерживать, и через группы, а не непосредственно отдельным людям. Отделите управление подписками и платформой от эксплуатации рабочих нагрузок, доступа к данным, развёртывания, наблюдения за безопасностью и выставления счетов. Там, где это поддерживается, используйте Privileged Identity Management для разрешённого повышения прав на ограниченное время; для действий с самыми тяжёлыми последствиями требуйте обоснование и согласование. Учётные записи аварийного доступа не должны зависеть от обычных служб; отслеживайте каждое их использование и отрабатывайте восстановление, не ослабляя повседневную аутентификацию.

Авторизация в приложении остаётся ответственностью самого приложения. Действующий маркер Microsoft Entra ID не доказывает принадлежность к клиентской среде, состояние учётной записи, право на операцию или владение запрошенным объектом. Проверяйте, кто выдал маркер, кому он предназначен, срок его действия и подпись, а затем обеспечивайте авторизацию на уровне ресурса в надёжном серверном коде. Журналируйте значимый доступ и административные изменения, не записывая в технические данные маркеры, секреты или чувствительное содержимое.

Предоставляйте рабочим нагрузкам идентичности, а не встроенные учётные данные

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

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

Секреты, ключи и сертификаты, без которых нельзя обойтись, храните в Azure Key Vault, а доступ предоставляйте через Microsoft Entra ID; для уровня данных отдавайте предпочтение Azure RBAC. Отделяйте администрирование хранилища от права читать его содержимое. Разделяйте хранилища по средам и существенным границам безопасности; настройте защиту от потери, сетевой доступ, диагностику, предупреждения об истечении срока и замену, которую потребляющее приложение способно пережить. Секрет, после замены которого служба перестаёт работать, нельзя считать правильно управляемым.

Каждая сетевая граница должна иметь ясную цель

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

Размещайте доступные из интернета службы HTTP за подходящими средствами защиты на внешнем рубеже и WAF, но воспринимайте правила WAF лишь как один из слоёв. Аутентификация, авторизация, обработка входных данных, ограничение злоупотреблений, обновления и безопасное проектирование приложения остаются необходимыми. Настраивайте управляемые и собственные правила на показательном потоке запросов, следите за исключениями и безопасно испытывайте блокирование: непроверенное исключение может стать постоянным путём в обход защиты. Планируйте защиту от DDoS по степени открытости и последствиям для бизнеса, а не исходите из предположения, что WAF остановит объёмные атаки.

Для поддерживаемых служб PaaS частные конечные точки и сетевые экраны служб могут устранить или ограничить открытый доступ. В то же время они усложняют DNS, маршрутизацию, работу средств сборки, доступ поддержки, наблюдение и восстановление. Проверьте разрешение имён и доступ из каждой необходимой среды, отключите открытый путь, если этого требует проект, и следите за отклонением настроек. Управляйте исходящим потоком так же осознанно, как входящим: перечислите необходимые адреса, принудительно направляйте поток через проверку там, где это оправдано, и сохраните проверенный путь для зависимостей платформы и аварийных действий.

Защищайте данные, чётко определив владельцев ключей и секретных данных

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

Выбирайте модель ключей по угрозе и распределению эксплуатационной ответственности. Шифрование с ключами платформы часто является подходящей исходной основой; ключи под управлением заказчика дают больше контроля над жизненным циклом и отзывом, но добавляют обязанности по доступности, правам, замене, восстановлению и разделению полномочий. Зафиксируйте иерархию ключей, администраторов, службы-потребители, регионы, поведение резервного копирования и восстановления, защиту от удаления, наблюдение, замену и последствия отключённого или недоступного ключа. Проверьте восстановление до того, как полагаться на отзыв как средство контроля.

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

Проектируйте технические данные для обнаружения угроз и расследований

Технические данные безопасности должны помогать расследованию, а не просто заполнять хранилище журналов. Начинайте с вопросов обнаружения и реагирования: какая идентичность изменила роль, открыла ресурс, прочитала секрет, отключила контроль, развернула программную составляющую, выгрузила данные, пересекла границу клиентской среды или создала необычную схему операций? Собирайте необходимые сигналы Microsoft Entra ID, Azure Activity, ресурсов, приложений, сети, Azure Key Vault, данных, автоматизированных процессов и конечных устройств с синхронизированным временем и устойчивыми идентификаторами.

Направляйте журналы в защищённое службой безопасности место с подходящими правилами доступа, хранения, целостности, расположения данных и стоимости. Уменьшайте количество чувствительного содержимого и не допускайте записи секретов или маркеров. Для каждого правила обнаружения назовите угрозу, зависимость от данных, ответственного, тяжесть, сценарий реагирования, ожидаемые ложные срабатывания и способ проверки. Испытывайте правила разрешёнными имитациями: отклонённым повышением прав, подозрительным входом, изменением открытости ресурса, аномальным чтением секрета, отключением диагностики или попыткой авторизации между клиентскими средами.

Defender for Cloud может добавить оценку состояния защиты, рекомендации, контекст DevSecOps и защиту рабочих нагрузок; Microsoft Sentinel или другая SIEM может сопоставлять сигналы и поддерживать расследование. Ни одна из них не заменяет работу службы безопасности. Определите, какие планы и ресурсы охвачены, кто проводит первичный разбор выявленных проблем, как устанавливается приоритет риска, когда оповещение становится инцидентом и как проверяется устранение. Следите и за самим потоком технических данных: отсутствующие журналы, сломанные соединители, неожиданное падение объёма и изменения прав являются сигналами безопасности.

Превратите требования в доказательства, которые можно проверить

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

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

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

Распределяйте общую ответственность для каждой службы отдельно

Применяйте модель общей ответственности отдельно к каждой выбранной службе Azure и модели развёртывания. Microsoft защищает основные физические объекты и уровни платформы, описанные в её обязательствах по службам; заказчик настраивает идентичности, доступ, данные, код приложений, многие сетевые средства, наблюдение и реагирование. Точная граница различается для виртуальных машин, управляемого Kubernetes, Azure App Service, Azure Functions, баз данных, хранилищ, служб идентичностей и сторонних SaaS. Не копируйте одну общую матрицу на всю среду.

Создайте реестр ответственности, где для каждой меры контроля названы внутренний ответственный, обязанности Microsoft, партнёр по реализации, поставщик программного обеспечения, управляемая служба безопасности и остаточный риск. Охватите исправления и версии среды исполнения, резервное копирование и восстановление, устранение уязвимостей, сертификаты, ключи, настройки платформы, доступность, запросы по данным, уведомление об инцидентах, расследования, регуляторную отчётность и общение с клиентами. Договорная ответственность, технический доступ и операционные возможности должны совпадать: возложенная на поставщика обязанность без доказательств или полномочий не передаёт ему риск.

Испытывайте места стыка ответственности. Разыграйте взлом администратора, утечку учётных данных нагрузки, уязвимую зависимость, открытие хранилища, нарушение работы региона, повреждение данных и сбой поставщика. Проверьте, кто обнаруживает, ограничивает, принимает решение, информирует, восстанавливает, сохраняет доказательства и выполняет последующие действия. Запишите пути связи и предположения о времени. Безопасную архитектуру поддерживают ответственность и тренировки, а не число служб на схеме.

Привлекайте независимую проверку на пересечении границ

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

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

• Идентичности людей: разделяйте группы идентичностей, сужайте роли, предоставляйте привилегии на ограниченное время, автоматизируйте найм, смену роли и завершение сотрудничества, защищайте аварийный доступ и проверяйте авторизацию на уровне ресурсов.
• Идентичности нагрузок и секреты: отдавайте предпочтение управляемой идентичности или объединению идентичностей, изолируйте права, ведите перечень назначений, защищайте Azure Key Vault с помощью RBAC и сетевых средств и доказывайте работоспособность замены и восстановления.
• Сетевые границы: обосновывайте открытые точки входа, разделяйте потоки, защищайте край сети, ограничивайте входящий и исходящий поток и проверяйте частный DNS, сборку, поддержку, наблюдение и пути отказа.
• Данные и ключи: классифицируйте данные на протяжении жизненного цикла, выбирайте владельца ключей по угрозе и ответственности, защищайте каждую копию и отрабатывайте процедуры с ключами, резервными копиями, выгрузкой, удалением и восстановлением.
• Обнаружение и реагирование: собирайте сигналы, пригодные для расследования, защищайте поток технических данных, проверяйте правила обнаружения имитациями, определяйте первичный разбор и передачу проблем и отрабатывайте ограничение и восстановление.
• Управление и доказательства: сопоставляйте применимые обязательства с мерами контроля, автоматизируйте проверенные правила безопасности, ограничивайте срок исключений, назначайте каждую общую ответственность и собирайте доказательства во время обычной работы.