Контроли облачной безопасности по UAE IA и DESC ISR
Переход в облако не меняет того, какие контроли применяются в ОАЭ. Он меняет того, кто способен их подтвердить. Регламент обеспечения информационной безопасности ОАЭ достаёт до облачных сред через существующие технические семейства, Регламент информационной безопасности DESC добавляет требования к поставщикам облачных услуг, обслуживающим правительство Дубая, а разрыв между ними лежит в модели разделённой ответственности, а не в одном из документов.
Эта страница показывает, чего два режима ОАЭ требуют от облачной инфраструктуры, на какой стороне разделённой ответственности лежит каждый контроль и как на самом деле определяется место хранения данных. Она написана для решения, которое принимается до проверки: можно ли вообще подтвердить такую архитектуру.
Короткий ответ. Облако не создаёт отдельного набора контролей в ОАЭ. По Регламенту обеспечения информационной безопасности ОАЭ действуют те же 188 контролей, а технические семейства с T1 по T9 достают до облачной инфраструктуры так же, как до любой другой. По Регламенту информационной безопасности DESC провайдеры, обслуживающие государственные организации Дубая, несут дополнительные требования по расположению, изоляции арендаторов, операционной прозрачности и правам на проверку. В обоих случаях меняются доказательства: контроль, которым управляет ваш провайдер, остаётся контролем, по которому проверяют вас, и единственные пути его подтвердить — договор или уже опубликованная провайдером аттестация. Место хранения решается классификацией данных и заказчиком по договору, а не общим правилом.
Какие семейства контролей достают до облака
Регламент не выделяет облачного приложения. Его 15 семейств действуют на инфраструктуру целиком, а для облачного сервиса проверка концентрируется на технических семействах. Идентификаторы ниже чаще всего оспариваются в облачных проектах, потому что у каждого есть версия, которой управляете вы, и версия, которой управляет провайдер. Полный набор контролей воспроизведён на нашей справочной странице UAE IA (NESA).
корпоративную инфраструктуру?
Запишитесь на технический брифинг. Без продаж, только архитекторы и ваша команда.
Эфемерная инфраструктура ломает реестр, рассчитанный на серверы. Облачные аккаунты, подписки, управляемые сервисы и хранилища данных внутри них должны быть в реестре, а реестр, обновляемый вручную, к моменту проверки будет устаревшим.
Теперь есть две плоскости идентификации: внутри ваших нагрузок и та, что администрирует сам облачный тенант. Проверки регулярно находят вторую без управления, с постоянным административным доступом и без записей о пересмотре.
Сегментация, выраженная группами безопасности и политикой, а не подсетями, и доказательство того, что действующая политика совпадает с утверждённой.
Журналы плоскости управления важны не меньше журналов нагрузок, а срок хранения должен пережить проверяемый период. Срок хранения по умолчанию в управляемых сервисах часто короче окна, о котором спросит аудитор.
Вопрос в том, у кого ключи, а не включено ли шифрование. Ключи под управлением провайдера, ключи под управлением клиента и ключи, хранимые вовне, дают три разных ответа на один и тот же контроль.
Провайдер — это поставщик. Его аттестации, их область действия и то, что происходит при её изменении, относятся к вашему реестру гарантий поставщиков, а не к папке закупок.
Требования к поставщикам облачных услуг
Там, где участвует государственная организация Дубая, Дубайский центр электронной безопасности применяет к поставщикам облачных услуг требования поверх набора контролей ISR. Их проверяют против того сервиса, который реально продаётся, и в том регионе, из которого он продаётся, — поэтому провайдер с сильными международными сертификатами всё равно может не пройти: эти сертификаты отвечают на вопрос, существует ли программа безопасности, а не на вопрос, удовлетворяет ли данный сервис в данном регионе условиям Дубая.
Основную часть работы дают четыре темы. Расположение: где физически находятся данные и их резервные копии и кто может до них дотянуться. Изоляция: что отделяет одного арендатора от другого и как это отделение доказывается, а не декларируется. Операционная прозрачность: что государственная организация видит об инцидентах, изменениях и людях с доступом. И проверка: какие права на обследование сервиса есть у организации или регулятора, — они должны быть в договоре, потому что задним числом их не добавить. Сам регламент кратко изложен на нашей справочной странице DESC ISR.
Где данные должны находиться
Сводки вендоров называют жёсткое правило, которого в первоисточниках нет. Размещение данных в ОАЭ определяется классификацией данных и требованиями заказчика по договору, поверх ложатся отраслевые правила, а для персональных данных — условия трансграничной передачи по закону ОАЭ о защите персональных данных. Самые жёсткие требования у государственных данных, и договор с правительством Дубая может прямо задать место хранения независимо от того, что позволил бы общий режим.
Практическая последовательность: сначала классификация, вторым — письменно зафиксированная позиция заказчика, третьим — проектирование архитектуры. Обратный порядок порождает самую дорогую категорию находок: ту, которую нельзя закрыть контролем, потому что требуется миграция. Резервные копии, регионы аварийного восстановления, приёмники журналов и пути доступа поддержки — вот где допущения о размещении рушатся чаще всего, поскольку каждый из них способен тихо вынести данные за пределы региона основного сервиса.
Модель разделённой ответственности — это документ, который пишете вы, а не тот, что выдаёт провайдер. Провайдеры публикуют разделение обязанностей для своей платформы. Наложить это разделение на конкретные идентификаторы контролей, по которым проверяют вас, — ваша работа, и контроли, попадающие между двумя описаниями, — ровно те, которые проверка находит бесхозными.
Облачные контроли в ОАЭ: частые вопросы
Применяются ли контроли UAE IA (NESA) к облачным нагрузкам?
Да, без изменений. Нет ни исключения для облака, ни отдельного облачного набора контролей. Действуют те же 188 контролей, а технические семейства с T1 по T9 достают до облачной инфраструктуры ровно так же, как до локальной. Отличаются доказательства: несколькими контролями управляет провайдер, а проверяют по ним вас, поэтому доказательство должно прийти через договор или опубликованную аттестацию.
Что такое стандарт безопасности поставщиков облачных услуг DESC?
Требования, которые DESC публикует для поставщиков облачных услуг, обслуживающих государственные организации Дубая, применяемые поверх ISR. Они сосредоточены на расположении, изоляции арендаторов, операционной прозрачности и правах на проверку и оцениваются против конкретного сервиса и региона, а не против общей программы безопасности. Для провайдера это условие входа на рынок; для покупателя позиция провайдера по ним становится частью его собственного пакета доказательств.
Должны ли наши данные оставаться внутри ОАЭ?
Зависит от классификации данных и от заказчика по договору, а не от одного общего правила. У государственных данных требования самые жёсткие, и государственный договор может прямо задать размещение. Персональные данные добавляют сверху условия передачи по PDPL, а отраслевые регуляторы — свои. Зафиксируйте позицию письменно до того, как утвердите архитектуру, и отдельно проверьте резервные копии, регионы аварийного восстановления, приёмники журналов и доступ поддержки: именно там допущения о размещении обычно рушатся.
Может ли гиперскейлер удовлетворить эти требования?
Часто да, и ответ даётся по сервису и по региону, а не по провайдеру. Провайдер может выполнять условия в своих регионах ОАЭ и в отдельных сервисах, тогда как управляемый сервис, которым вы тоже пользуетесь, обрабатывает или хранит данные в другом месте. Проверяют развёрнутую вами архитектуру, поэтому полезный вопрос — какие сервисы в каких регионах, а не чей логотип стоит в договоре.
Кто подтверждает контроль, которым управляет провайдер?
Вы, тем, что даёт провайдер. На практике это действующая аттестация, область которой покрывает используемые сервис и регион, договорные обязательства там, где аттестации нет, и ваши собственные доказательства для той части контроля, что лежит на вашей стороне. Контроль, по которому доказательств нет ни у одной стороны, — это находка, и в первой облачной проверке самая частая.
У нас уже есть ISO 27001 в облаке. Этого достаточно?
Это сильное начало для управленческих семейств, и оно не отвечает на вопросы, специфичные для ОАЭ. ISO 27001 удостоверяет, что система управления существует и работает; он не касается требований к размещению данных, условий DESC для работы с правительством Дубая и конкретных технических идентификаторов контролей, по которым вас будут оценивать. Ожидайте, что сопоставление перенесётся, а пробелы сконцентрируются в деталях доказательств и в разделении облачной ответственности.
Где мы делаем эту работу
Все 188 контролей проверены по доказательствам и оценены по уровням, за четыре-шесть недель. Анализ пробелов NESA в ОАЭ.
Закрытие того, что нашёл отчёт о пробелах, в порядке, который ожидает проверка. Внедрение NESA в ОАЭ.
Gap-анализ по каждому контролю против этого фреймворка, каждая находка с доказательством. Оценка информационной безопасности в Дубае.
Определение регуляторного периметра, моделирование угроз и архитектура нулевого доверия для групп, работающих в Эмиратах. Консалтинг по кибербезопасности в Дубае.
Один набор контролей, сопоставленный со всеми обязательными для вас стандартами, и конвейер доказательств за ним. Управление ИБ в ОАЭ.