- tocdepth
2
Создание Landing Zone
Облака обеспечивают безопасность, устойчивость, качество обслуживания, эффективность эксплуатации и экономичность. Из-за этого все больше предприятий переносят свои системы в облака и предпочитают разрабатывать перспективные облачно-ориентированные приложения. При этом предприятиям зачастую необходимо:
Изолировать системы безопасности и сбои в работе отдельных служб, чтобы обеспечить разделение облачных ресурсов, приложений и данных всех служб.
Гибко настроить облачные ресурсы.
Спроектировать сетевую архитектуру для нескольких сервисов (или даже облачных платформ) и установить сетевую связанность между локальными ЦОДами и облаком.
Спланировать среду разработки, тестирования и продуктивную среду.
Организовать совместное использование общих ресурсов несколькими сервисами.
Централизованно управлять бюджетами и расходами каждой системы и оптимизировать затраты на облачную инфраструктуру.
Предотвратить чрезмерное использование облачных ресурсов различными системами.
Выделить группы пользователей и установить разрешения для этих групп.
Для решения всех этих вызовов Cloud.ru разработал Landing Zone — структуру целевой зоны для эффективного управления группами сервисов, пользователями, правами доступа, облачными ресурсами, данными, приложениями, затратами и средствами безопасности.
Термин Landing Zone означает пространство в публичном облаке, куда можно плавно переносить корпоративные сервисные системы. Решение Landing Zone от компании Cloud.ru позволяет создать в облаке безопасную, соответствующую требованиям и масштабируемую среду, в которой множество учетных записей могут совместно использовать ресурсы. Управление персоналом, финансами, ресурсами, правами доступа, а также выполнение требований безопасности в такой среде унифицировано.
Персонал: унифицированное управление группами сервисов, учетными записями, пользователями, группами пользователей и ролями для всех учетных записей.
Финансы: унифицированное управление денежными средствами через облачную платформу.
Ресурсы: унифицированная эксплуатация и техническое обслуживание, мониторинг и управление облачными ресурсами, в том числе вычислительными, сетевыми, хранилищами, приложениями и данными для всех учетных записей.
Разрешения: унифицированное управление правами доступа на использование облачных ресурсов несколькими учетными записями на основе принципа наименьших привилегий (PoLP).
Безопасность: унифицированное управление соблюдением требований безопасности, действующих для соответствующих стран, отраслей и предприятий.
Эталонная архитектура Landing Zone
Персонал, финансы, ресурсы, права доступа и требования безопасности сопоставляются со структурой учетных записей и организационной структурой, принципами управления финансами, планирования сети, проектирования системы идентификации и правами доступа, обеспечения безопасности и аудита соответствия требованиям.
Структура учетных записей и организационная структура
Для Landing Zone требуется безопасная, соответствующая требованиям и масштабируемая мультиаккаунтная облачная среда. Ее создание рекомендуется начинать с планирования структуры учетных записей и организационной структуры.
Cloud.ru предоставляет эталонную структуру. Проектирование организационных уровней и учетных записей рекомендуется выполнять с учетом бизнес архитектуры и функций ИТ.
Облачное решение Cloud.ru позволяет в соответствии с архитектурой сервисов определить различные организационные уровни и организационные единицы (ОЕ). Для каждой сервисной ОЕ на основе систем сервисов можно создать индивидуальные учетные записи участников организации. В зависимости от масштабов сервисов и требований по разделению могут создаваться индивидуальные или общие учетные записи.
Чтобы разделить функциональные обязанности и права доступа в домене управления IT и обеспечить управление множеством учетных записей участников, для основного отдела IT предприятия на платформе Cloud.ru создаются соответствующие организационные единицы и учетные записи для всех функций IT (приведены в таблице ниже).
Роль |
Функция ИТ |
Группа ответственных исполнителей |
Ресурс или облачный сервис |
|---|---|---|---|
Администратор сети |
Централизованное развертывание и управление сетевыми ресурсами предприятия, включая средства безопасности границ сети, с целью унификации управления сетевыми ресурсами и взаимодействия между виртуальными частными облаками (VPC) из-под нескольких учетных записей. В частности централизованное управление входящим и исходящим сетевым трафиком как к локальному оборудованию, так и к трафику, направленному в интернет. |
Группа управления сетью и группа управления безопасностью |
|
Администратор сервисов |
Централизованное развертывание и управление корпоративными публичными ресурсами, сервисами и системами приложений, а также предоставление доступа к ним другим учетным записям участников. |
Группа управления публичными сервисами |
|
Администратор безопасности |
|
Группа управления безопасностью |
Сервисы, поддерживающие межаккаунтный контроль безопасности (DEW, HSS и CGS) |
Администратор мониторинга |
Внедрение средств унифицированного мониторинга и ЭиТО ресурсов и приложений для каждой учетной записи участника организации, а также своевременное выявление потенциальных проблем и рассылка предварительных уведомлений. |
Группа эксплуатации и технического обслуживания |
|
Администратор аудита |
Централизованное хранение журналов выполнения операций и журналов аудита других учетных записей |
Группа анализа журналов и группа аудита соответствий |
|
Администратор платформы данных |
Централизованное развертывание платформы больших данных предприятия, а также сбор служебных данных других учетных записей на платформе данных для хранения, обработки и анализа. |
Группа обработки данных и группа бизнес-анализа |
|
Администратор DevOps |
Централизованное управление конвейерами CI/CD в масштабах всего предприятия и развертывание их для разных учетных записей. |
Группа исследований и разработки ПО |
|
Администратор тестовой среды (песочницы) |
Тестирование функций и политик безопасности облачных сервисов |
Группа тестирования |
Ресурсы и сервисы по требованию, которые необходимо протестировать |
Помимо этих ролей при необходимости можно создать дополнительные роли, например, роль для интеграции приложений.
По умолчанию главная учетная запись создается в корневом узле организации. От имени этой учетной записи не рекомендуется разворачивать облачные ресурсы. Используйте главную учетную запись для следующих задач:
Централизованное управление организациями и учетными записями. Создание организационных структур и организационных единиц и управление ими, создание роли для ОЕ или приглашение существующих учетных записей в организацию в качестве участников.
Централизованное управление финансами. Сбор статистики и анализ затрат предприятия на инфраструктуру Cloud.ru осуществляется через облачную платформу.
Централизованное управление организационными политиками. Установление организационных политик для ОЕ и учетных записей участников, принудительное ограничение прав доступа пользователей для учетных записей участников (в том числе и для администраторов) с целью предотвратить угрозы безопасности, связанные с избыточными правами доступа. Если организационная политика применяется к определенной ОЕ, то она действует в отношении всех учетных записей ее участников и входящих в нее организационных единиц более низкого уровня.
Для детализированной группировки ресурсов по учетным записям участников можно использовать корпоративные проекты или теги. Например, подсистемы приложений или подпродукты можно объединить в один корпоративный проект или установить для них тег. Также на основе этих группировок предусмотрена возможность осуществить подробный контроль прав доступа записей участников.
Планирование сети
Миграция инфраструктуры и приложений заказчика в облако требует надлежащего планирования сетевой архитектуры. Необходимо оценить текущее состояние сети ЦОДа, продумать разграничение доступа и спланировать сети для облака, включая VPC, подсети и связь между облачными и локальными сетями.
- Оценка существующей сети ЦОДа
Чтобы спланировать разграничение доступа и подключение к сети, оцените текущее состояние локальной сети ЦОДа:
Функции и сервисы, предоставляемые каждым ЦОДом.
Сопоставление локальных ЦОДов с регионами и зонами доступности в облаке.
Сетевая архитектура внутри ЦОДов и между ними.
Распределение прикладной системы и потока данных между сервисами.
- Проектирование многопользовательской сети
Разработка структуры учетных записей для облака осуществляется в соответствии с планом сети. При этом рассматриваются три сценария:
Одна учетная запись и одна сеть VPC: управление учетными записями и ввод в эксплуатацию просты, поскольку команда небольшая, но уровень безопасности низкий.
Одна учетная запись и несколько сетей VPC: простое и удобное управление учетной записью с высоким уровнем безопасности. Виртуальные частные облака обеспечивают различную функциональность и предусматривают разные правила контроля доступа.
Несколько учетных записей или главная учетная запись, дополнительные учетные записи и несколько сетей VPC: управлять учетными записями сложнее из-за большой численности группы, охватывающей несколько филиалов и комплексных сервисов. Соблюдение требований безопасности также может оказаться сложной задачей. Если в одном регионе развернуто несколько сетей VPC, для их соединения следует использовать VPC Peering Connection.
Первый и второй сценарии достаточно простые. В большинстве случаев они подразумевают использование одной сети VPC и планирование подсетей. Подробнее см. в разделе Планирование и проектирование облачных сетей.
Третьему сценарию будет посвящен следующий раздел.
В основе этой архитектуры лежит учетная запись для эксплуатации сети, которая является связующим звеном между различными учетными записями. Связь ресурсов разных учетных записей обеспечивает соединение VPC Peering Connection. Оно позволяет конфигурировать маршруты, которые определяют, какие сети VPC могут взаимодействовать между собой.
В большой системе сервисов обычно имеются независимые дополнительные учетные записи. Рекомендуется создать три виртуальных частных облака — производственное VPC, VPC для разработки и тестовое VPC. В системе сервисов эти виртуальные частные облака изолированы друг от друга. В каждом VPC должно быть как минимум две подсети — подсеть приложений и подсеть данных. Первая из них соответствует уровню приложений, а вторая — уровню данных. Для управления доступом к подсетям используются Network ACL — сетевые списки контроля доступа. Такие ресурсы, как серверы ECS и инстансы DCS и RDS, можно добавлять в группы безопасности для управления доступом на уровне инстансов в соответствии с правилами групп. Для обеспечения высокой доступности на прикладном уровне кластеры приложений систем сервисов могут быть развернуты в зонах доступности. Для обеспечения высокой доступности на уровне данных используются активные/резервные кластеры баз данных и кластеры на базе распределенных сервисов кеширования данных (DCS) в зонах доступности Cloud.ru.
Несколько небольших систем сервисов, к которым не предъявляются строгие требования к безопасности, могут совместно использовать одну и ту же дополнительную учетную запись. Рекомендуется создать три виртуальных частных облака (VPC) — производственное VPC, VPC для разработки и тестовое VPC. Развертывание сервисных систем в разных подсетях позволяет сделать их изолированными. Каждая сервисная система имеет свою собственную независимую подсеть приложений и подсеть данных. Эти подсети связаны с Network ACL для управления доступом.
Примечание
Для каждой сервисной системы небольшого масштаба рекомендуется создать корпоративный проект, связать ресурсы каждой системы в производственном VPC, тестовом VPC и в VPC для разработки с одним и тем же корпоративным проектом или тегом, а также организовать сбор данных о затратах и детальную авторизацию на основе корпоративного проекта или тегов.
- Планирование и проектирование облачных сетей
Следующие варианты включают VPC и подсеть в облаке, интернет-соединения в облаке, сеть эксплуатации и технического обслуживания в облаке, а также подключения между сетью облака и сетью предприятия.
- VPC и подсети в облаке
- VPC:
Каждое виртуальное частное облако может включать до 5000 IP-адресов.
VPC изолированы по умолчанию. Для организации их взаимодействия можно использовать VPC Peering Connection.
Поддерживаются несколько типов VPC: VPC O&M, VPC в DMZ и сервисные VPC. Разные виртуальные частные облака связаны с помощью VPC Peering Connection.
Каждое сервисное виртуальное частное облако принадлежит отдельной системе сервисов или подразделению. Системы сервисов или подразделения, не требующие доступа друг к другу, разворачиваются в разных виртуальных частных облаках.
Виртуальные машины можно развернуть во всех AZs. Это обеспечивает высокую доступность сервисов.
По умолчанию производственный VPC изолирован от виртуальных серверов разработки и тестирования. Между ними не установлено VPC Peering Connection. Для передачи данных рекомендуется использовать объектное хранилище OBS.
- Подсети:
Корпоративные подсети должны быть спланированы таким образом, чтобы их диапазоны адресов не пересекались.
Подсети в одном VPC не должны пересекаться.
Разные системы сервисов должны быть развернуты в разных подсетях. Для управления доступом между подсетями можно использовать Network ACL.
Для развертывания приложений и хранения данных следует использовать разные подсети. По умолчанию доступ к подсетям данных возможен только из подсетей приложений. При необходимости доступ к подсетям приложений можно получить из других подсетей или из интернета.
При необходимости возможен доступ к подсетям эксплуатации и технического обслуживания из других подсетей.
- Организация взаимодействия с интернетом
Решение 1: использование Web Application Firewall (WAF) для защиты веб-сервисов.
Чтобы очистить трафик, используйте инструмент Anti-DDoS для адресов EIP. В случае высокой интенсивности трафика используйте Advanced Anti-DDoS.
Чтобы перенаправить доменные имена на WAF, добавьте запись CNAME в настройки DNS.
Используйте WAF для защиты имен веб-доменов, а затем перенаправьте трафик сервису ELB.
Чтобы разрешить доступ только с IP-адресов WAF, используйте белый список ELB.
Чтобы разрешить доступ только из определенных диапазонов IP-адресов через определенные порты, используйте группу безопасности серверов ECS в подсети приложения.
Чтобы разрешить взаимодействие только с IP-адресами WAF и подсетью базы данных, используйте ACL подсети приложений.
Чтобы разрешить доступ только из подсети приложений к IP-адресу и порту базы данных, используйте ACL подсети базы данных.
Используйте группу безопасности базы данных, чтобы ограничить порты и диапазоны IP-адресов, к которым она может получить доступ.
Host Security Service и Database Security Service являются альтернативными способами обеспечения безопасности.
Решение 2: без использования WAF для защиты веб-сервисов.
Чтобы очистить трафик, используйте инструмент Anti-DDoS для адресов EIP. В случае высокой интенсивности трафика используйте Advanced Anti-DDoS.
Настройте DNS для разрешения доменного имени в адрес EIP сервиса ELB.
(Опционально) Чтобы разрешить доступ только из определенных диапазонов IP-адресов, используйте черный и белый списки ELB.
Чтобы разрешить доступ только из определенных диапазонов IP-адресов через определенные порты, используйте группу безопасности серверов ECS в подсети приложения.
Чтобы разрешить взаимодействие только с подсетью базы данных, используйте ACL подсети приложения.
Чтобы разрешить доступ только из подсети приложений к IP-адресу и порту базы данных, используйте ACL подсети базы данных.
Используйте группу безопасности базы данных, чтобы ограничить порты и диапазоны IP-адресов, к которым она может получить доступ.
Host Security Service и Database Security Service являются альтернативными способами обеспечения безопасности.
Специалисты по обслуживанию корпоративных информационных систем могут получить доступ к внутренней сети предприятия через публичное VPC для эксплуатации и технического обслуживания и осуществлять эксплуатацию и обслуживание облачных ресурсов с помощью платформы Cloud Bastion Host (CBH).
Публичное VPC для эксплуатации и технического обслуживания обменивается данными с другими VPC с помощью VPC Peering Connection. Network ACL настроены таким образом, чтобы разрешать локальным подсетям доступ только к тем подсетям, которые предоставляют внешние сервисы в облаке. Сопровождение всех инстансов осуществляется только через подсеть эксплуатации и технического обслуживания.
Network ACL и группа безопасности подсети эксплуатации и технического обслуживания разрешают доступ только из определенных локальных подсетей.
Для контроля взаимодействия с подсетью эксплуатации и технического обслуживания через определенные порты каждое VPC использует Network ACL.
Все операции технического обслуживания должны выполняться на платформе CBH. Эксплуатационные процессы регистрируются с возможностью аудита.
- Связь сети облака и сети предприятия
В приведенной ниже таблице по ряду параметров сравниваются различные сервисы, которые можно использовать для организации подключений между сетями в облаке и сетями предприятия. Можно выбрать вариант, наиболее точно соответствующий требованиям.
Сравниваемые параметры |
Direct Connect |
VPN |
Сеть SD-WAN |
|
|---|---|---|---|---|
Архитектура |
Качество сети |
Высокое, гарантируется выполнение SLA |
Низкое, без гарантии выполнения SLA |
Подключение к интернету осуществляется в ближайшей активной или резервной точке присутствия (POP). Сервис Direct Connect использует магистральную сеть и обеспечивает выполнение SLA. |
Гибкость сети |
Низкая. Начисления и тарификация выполняются раз в год, есть сложности с настройкой пропускной способности. |
Высокая. Биллинг с оплатой по факту использования, есть возможность изменить пропускную способность при необходимости. |
Начисления и тарификация выполняются раз в год, пропускная способность может гибко регулироваться. |
|
Зависимость от оборудования |
Универсальный маршрутизатор |
Универсальное оборудование VPN |
Отдельно приобретенные устройства SD-WAN |
|
Расширенные сервисы |
Нет |
Нет |
Сервисы безопасности |
|
Затраты |
Линии подключения |
Высокие (10-кратные) |
Низкие (1-кратные) |
Средние (3-кратные) |
Время развертывания |
Месяцы |
Часы |
Дни (включая доставку оборудования) |
|
Техническое обслуживание |
Необходим высококвалифицированный персонал, отсутствует унифицированное управление. |
Необходим высококвалифицированный персонал, отсутствует унифицированное управление. |
Высококвалифицированный персонал не требуется, простая настройка на месте, унифицированное облачное управление и гарантированное качество сети. |
|
Подключение сетей ЦОДа, кампусов, филиалов и мобильных офисов предприятий к Cloud.ru
- ЦОД/кампус на территории предприятия:
Такой ЦОД или кампус безопасно и надежно подключен к Cloud.ru, имеет доступ в интернет через ресурсы в облаке, что позволяет снизить затраты, и может через частную сеть напрямую использовать публичные облачные сервисы.
- Решение 1:
Для подключения к публичному VPC для эксплуатации и технического обслуживания в Cloud.ru используйте сервис Direct Connect (одну или две частные линии).
- Решение 2:
Для подключения к публичному VPC для эксплуатации и технического обслуживания в Cloud.ru используйте IPsec VPN.
- Филиалы:
Предприятию с несколькими филиалами необходимо обеспечить для каждой из сетей безопасные подключения к Cloud.ru с низкими задержками.
- Решение 1:
Для подключения к публичному VPC для эксплуатации и технического обслуживания в Cloud.ru используйте IPsec VPN.
- Решение 2:
Для подключения локального ЦОДа или кампуса к публичному VPC для эксплуатации и технического обслуживания в Cloud.ru используйте VPN или сервис Direct Connect.
- Мобильные офисы или магазины:
У предприятия может быть множество офлайн-магазинов или филиалов. Бизнес-системы (например, мобильные POS-системы) должны в реальном времени взаимодействовать с облачными системами (например, ERP). Для этого требуется надежное шифрование и низкая сетевая задержка. Публичная сеть не гарантирует безопасность и стабильность работы, а Direct Connect является дорогостоящим решением.
- Решение 1:
Для подключения к публичному VPC для эксплуатации и технического обслуживания в Cloud.ru используйте SSL VPN.
- Решение 2:
Для подключения локального ЦОДа или кампуса к публичному VPC для эксплуатации и технического обслуживания в Cloud.ru используйте VPN или сервис Direct Connect.
- Миграция локальных серверов в облачную инфраструктуру без изменения IP-адресов
Иногда заказчики отказываются менять IP-адреса своих систем после переноса в облако, чтобы быть уверенными в непрерывности функционирования сервисов.
- Решение:
Cloud.ru предлагает виртуальный шлюз Layer 2 Connection Gateway (L2CG), позволяющий облачным сетям и сетям предприятия обмениваться данными на втором уровне. Миграция выполняется с сохранением существующей IP-адресации, что позволяет исключить влияние на работу сервисов в процессе переноса.
- Доступ к локальному ЦОДу через частную сеть
Вместо того, чтобы использовать интернет-подключения, корпоративные пользователи получают доступ к облачным сервисам (таким как OBS, SWR и API Gateway) непосредственно через частную сеть.
- Решение:
После подключения локального ЦОДа к Cloud.ru с использованием сервиса Direct Connect или VPN ЦОД получает доступ к облачным сервисам через частную сеть с помощью VPC Endpoint, что является безопасным, эффективным и экономичным способом.
- Локальный ЦОД с доступом в интернет через Cloud.ru
Если публичная сеть, которую использует ЦОД, отличается недостаточно хорошим качеством и высокой стоимостью, его можно подключить к Cloud.ru с помощью сервиса Direct Connect. Тогда ЦОД сможет использовать для доступа в интернет облачные ресурсы, что позволит одновременно и снизить затраты, и повысить качество доступа к публичной сети.
- Решение 1:
С помощью Direct Connect и DNAT сеть предприятия и облачная сеть совместно используют точку выхода публичной сети.
- Решение 2:
С помощью Direct Connect и SNAT офисы кампуса совместно используют для доступа в интернет точку выхода публичной облачной сети.
- Пересечение диапазонов IP-адресов
Рассмотрим ситуацию, когда отделы предприятия используют пересекающиеся подсети. Предприятие решило перейти в облако, но хочет сохранить подсети без изменений и обеспечить отделам возможность взаимодействовать друг с другом после миграции.
- Решение:
Cloud.ru предоставляет частные NAT-шлюзы для отображения частных IP-адресов. Для преобразования IP-адреса сервисного отдела можно создать транзитное VPC и использовать частный NAT-шлюз. IP-адресу 192.168.0.3, используемому сервисным отделом, будет сопоставлен IP-адрес 10.0.0.33, а IP-адресу 192.168.0.3, используемому отделом безопасности — IP-адрес 10.0.0.22. Таким образом, два отдела могут взаимодействовать друг с другом, даже если их подсети пересекаются.
- Балансировка нагрузки в облаке и в сети предприятия
В этом сценарии некоторые сервисы по-прежнему работают на оборудовании, находящемся в аппаратном зале предприятия, и используют балансировщик нагрузки ELB в облаке для предоставления сервисов внешним системам. Облачные ресурсы расширяют возможности ЦОДа по обработке пиковой нагрузки трафика.
- Решение:
Используйте балансировщик нагрузки ELB, чтобы распределять трафик между облачными и локальными ресурсами.
Разработка системы идентификации пользователей и разрешений
Опираясь на множество успешно реализованных проектов, подразделение Cloud.ru сформулировало следующие принципы управления пользователями и разрешениями:
Установите доверительные отношения между корпоративной системой управления идентификацией пользователей (например, AD) и сервисом Cloud.ru IAM, чтобы задействовать механизм федеративной аутентификации (federated authentication), благодаря которому сотрудники предприятия смогут использовать однократную авторизацию (SSO) в консоли Cloud.ru. Корпоративная система управления идентификацией позволяет более тщательно контролировать выдачу сотрудникам разрешений при приеме на работу и своевременно отзывать разрешения у тех сотрудников, которые перешли в другие отделы или уволились.
Не следует использовать Cloud.ru IAM в качестве корпоративной системы управления пользователями. Нет необходимости создавать пользователей или группы пользователей в Cloud.ru IAM для сотрудников, которые не взаимодействуют с Cloud.ru.
Не следует сообщать пароли другим лицам. Вместо этого создайте отдельного пользователя и назначьте ему разрешения в соответствии с требованиями специалистов, которым необходимо управлять ресурсами Cloud.ru или использовать их. Такой подход позволит также отслеживать все операции, выполняемые в Cloud.ru, и проводить их аудит.
Рекомендуется создать группы пользователей на основе функций IT и добавить в них сотрудников в соответствии с их обязанностями. Например, для повышения эффективности эксплуатации и технического обслуживания (ЭиТО) ресурсов и управления ими применяйте принципы унифицированного управления и обслуживания. От имени учетной записи ЭиТО и мониторинга создайте группы пользователей в соответствии с обязанностями отдела ЭиТО. К таким группам пользователей относятся группа управления вычислительными ресурсами, группа управления ресурсами хранения, группа управления сетью и группа управления базами данных.
Следуйте принципу минимальных привилегий (PoLP). Предоставляйте группам пользователей только минимально необходимый уровень доступа или разрешений. Если обязанности группы пользователей изменяются, своевременно корректируйте разрешения. Чтобы упростить операции, предоставляйте разрешения группам пользователей, а не отдельным пользователям.
Администратор учетной записи IAM (с тем же именем, что и пользователь IAM — главная учетная запись) имеет максимальные права доступа. Поэтому не следует использовать эту учетную запись для прямого доступа к Cloud.ru. Вместо этого создайте пользователя IAM и предоставьте ему по принципу PoLP разрешения для выполнения различных операций управления, обеспечив тем самым безопасность учетных записей IAM.
На основе этих принципов осуществляется планирование групп пользователей для учетных записей в Landing Zone. Этим группам пользователей по принципу PoLP назначаются соответствующие разрешения на доступ к облачным сервисам в Cloud.ru. Группы пользователей в корпоративной системе управления идентификацией сопоставляются с группами пользователей в Cloud.ru таким образом, чтобы они получили соответствующие разрешения на доступ к облачным сервисам.
Для обеспечения унифицированного управления и контроля функциональные учетные записи Landing Zone должны иметь возможность доступа к облачным ресурсам и управления ими от имени других учетных записей с использованием механизма делегирования полномочий между учетными записями (cross-account delegation). Например, учетная запись безопасности создана для централизованного управления ресурсами и сервисами безопасности (такими как SA и HSS), принадлежащими разным учетным записям, посредством механизмов federated authentication и cross-account delegation. Администратор безопасности заходит в консоль учетной записи безопасности через SSO, меняет роль на сервисную учетную запись, а затем получает доступ к облачным сервисам безопасности и управляет ими от имени этой учетной записи.
Другой подобный сценарий предполагает, что учетная запись ЭиТО и мониторинга может получать доступ к ресурсам от имени других учетных записей с помощью механизмов federated authentication и cross-account delegation, чтобы осуществлять мониторинг и управление ресурсами для всех учетных записей предприятия.
Безопасность
Защита области Landing Zone включает в себя следующие аспекты:
Безопасность виртуальной сети.
Безопасность хоста.
Безопасность приложений.
Защита данных.
Управление безопасностью.
- Безопасность виртуальной сети
Virtual Private Cloud (VPC) позволяет создавать изолированные, настраиваемые и управляемые виртуальные сети для виртуальных серверов Elastic Cloud Servers (ECS), повышая безопасность облачных ресурсов и упрощая развертывание сетей для сервисных систем.
Соответствующие функции VPC:
Подсеть: диапазон IP-адресов внутри VPC, в котором обеспечивается управление IP-адресами и разрешение имен DNS для виртуальных серверов ECS этой подсети. По умолчанию виртуальные серверы ECS, используемые во всех подсетях одного и того же VPC, могут взаимодействовать друг с другом — в отличие от серверов ECS, используемых в разных VPC.
Network Access Control List (Network ACL): позволяет создавать правила для управления входящим и исходящим трафиком одной или нескольких подсетей.
Группа безопасности: представляет собой набор правил управления доступом для виртуальных серверов ECS, которые имеют одинаковые требования к защите безопасности и являются взаимно доверенными внутри одного VPC. Правила доступа для ECS можно определить в группе безопасности и между группами безопасности.
Virtual Private Network обеспечивает безопасный зашифрованный канал связи для удаленных пользователей, с помощью которого они могут использовать ресурсы VPC. По умолчанию виртуальные сервера ECS в виртуальном частном облаке не могут обмениваться данными с пользовательскими ЦОДами или частными сетями. Чтобы обеспечить их взаимодействие, используется VPN.
Direct Connect обеспечивает частную линию для связи локального ЦОДа с облаком. С помощью Direct Connect пользователи могут подключать локальные ЦОДы, офисы и прочие зоны к облаку, что уменьшает задержку в сети и обеспечивает высокоскоростное и безопасное соединение.
- Безопасность хоста
Безопасность хоста виртуальной сети обеспечивается Host Security Service и Container Guard Service.
Host Security Service (HSS) позволяет: - идентифицировать активы на серверах и управлять ими; - управлять программами, целостностью файлов, операциями безопасности и уязвимостями; - проверять наличие небезопасных настроек; - в режиме реального времени противостоять угрозам, вторжениям и фальсификациям веб-страниц.
Кроме того, предусмотрены расширенные функции защиты и обеспечения безопасности, которые помогут с легкостью обнаруживать угрозы и справляться с ними. HSS обеспечивает обнаружение вторжений, управление целостностью файлов, мониторинг удаленного входа в систему, защиту от программ-вымогателей, унифицированное управление активами, управление уязвимостями, базовые проверки, защиту от подмены веб-страниц, а также поддерживает определяемые пользователем политики.
Container Guard Service (CGS) позволяет: - сканировать образы контейнеров на наличие уязвимостей; - управлять политиками безопасности контейнеров; - предотвращать атаки типа «побег из контейнера».
CGS помогает контролировать уязвимости, вносить процессы в белый список, обеспечивать защиту файлов и отслеживать время выполнения.
- Безопасность приложений
Безопасность приложений обеспечивается посредством WAF и Anti-DDoS.
Web Application Firewall (WAF) — межсетевой экран уровня приложений для выявления и блокировки атак на веб-приложения. Он находит и блокирует множество распространенных атак, таких как внедрение SQL-кода, межсайтовый скриптинг (XSS), удаленное выполнение команд и кода, обход каталогов, получение доступа к конфиденциальным данным, атаки Challenge Collapsar (CC), вредоносные поисковые боты и межсайтовая подделка запросов (CSRF).
Anti-DDoS — инструмент противодействия кибератакам. Услуга фильтрации трафика в целях обеспечения стабильности и бесперебойности работы информационных ресурсов клиента по протоколам HTTP или HTTPS, осуществляемая на основе анализа и обработки трафика клиента в интернете. После подключения Anti-DDoS перенаправляет запросы к сайтам и веб-сервисам через облако Qrator, которое анализирует и фильтрует трафик. Облако Qrator создано специально для защиты и стабильной работы в условиях DDoS-атаки. Узлы фильтрации в нем подключены к сетям крупнейших интернет-провайдеров России, США, Европы и Юго-Восточной Азии и сохраняют стабильность даже при экстремальном уровне нагрузки. Атака на какой-либо сайт не сказывается на работе сайтов других абонентов.
- Защита данных
В рамках публичного облака сервис Data Encryption Workshop (DEW) интегрирован с несколькими облачными сервисами — Elastic Volume Service (EVS), Object Storage Service (OBS) и Scalable File Service (SFS). API-интерфейсы DEW позволяют разрабатывать собственные приложения для шифрования.
Ключи шифрования DEW включают в себя ключи шифрования данных (DEK), мастер ключи клиента (CMK) и корневые ключи. На рисунке ниже показана их связь.
DEK шифруются с помощью CMK, а CMK защищены корневыми ключами. Корневой ключ генерируется с помощью технологии UKey при инициализации стороннего оборудования и доступен пользователям и поставщикам облачных услуг.
Database Security Service. DBSS позволяет обнаруживать атаки с внедрением SQL-кода, управлять операциями, связанными с большим риском, и проводить аудит баз данных.
- Управление безопасностью
Управление безопасностью виртуальной сети осуществляется с помощью сервиса IAM и платформы CBH.
Identity and Access Management (IAM) обеспечивает детальную иерархическую авторизацию, позволяющую контролировать операции клиента и использование им ресурсов от имени корпоративной учетной записи. Можно настраивать политики паролей, политики доступа в систему, Network ACL, многофакторную аутентификацию (MFA) и управлять разрешениями, что позволяет предотвратить выполнение несанкционированных операций отдельными пользователями.
Cloud Bastion Host предлагает различные функциональные модули и оперирует следующими сущностями: департамент, пользователь, ресурс, политика, операция и аудит. CBH включает в себя функции единого входа (SSO) и унифицированного управления активами, поддерживает протоколы многотерминального доступа, а также передачу файлов и совместную работу в рамках сеансов. Благодаря унифицированному входу в систему ЭиТО, прокси-серверу переадресации и технологиям изоляции удаленного доступа CBH обеспечивает централизованный, упрощенный и безопасный аудит облачных ресурсов — серверов, облачных хостов, баз данных и систем приложений.
Аудит соответствия
Чтобы гарантировать, что после миграции в облако среда выполнения предприятия соответствует национальным, отраслевым и корпоративным требованиям безопасности, решение Landing Zone предлагает следующие меры обеспечения безопасности:
Разграничение обязанностей. Для Separation of duty (SOD) используется мультиаккаунтная архитектура. Каждая учетная запись — это единица SOD. Предприятие может группировать учетные записи по сервисным, географическим и функциональным единицам. Благодаря ограничению пределов влияния потеря какой-либо учетной записи не сказывается на системе в целом.
Аудит операций. Функция аудита операций предусмотрена для каждой учетной записи, поэтому каждый раз, когда какой-либо объект получает доступ к ресурсу, это действие регистрируется. Все операции можно отслеживать. Хранение и анализ журналов аудита всех учетных записей осуществляются централизованно.
Отслеживание изменений конфигурации. Для каждой учетной записи активирована запись конфигурации ресурсов, что позволяет регистрировать любые изменения. Все изменения ресурсов отслеживаются. Хранение и анализ журналов изменений осуществляются централизованно.
Барьер безопасности. Поддерживаются два типа барьеров безопасности — соответствующие ее критическому (красные линии) и базовому уровням.
Красные линии безопасности, также называемые превентивными барьерами безопасности, принудительно ограничивают разрешения учетных записей участников, позволяя избежать угроз безопасности в связи с избыточными разрешениями. Для определения красных линий безопасности может использоваться упомянутая ранее детальная авторизация (fine-grained).
Базовые уровни безопасности, также называемые барьерами обнаружения, требуют, чтобы учетные записи участников соответствовали основным требованиям безопасности. Например, для привилегированного пользователя должна быть включена функция многофакторной аутентификации (MFA), а диски EVS должны быть зашифрованы.
Унифицированное управление идентификацией и разрешениями. Управление пользователями, группами пользователей и разрешениями в мультиаккаунтной среде осуществляется централизованно, чтобы пользователь мог получать доступ к ресурсам от имени нескольких учетных записей. Унифицированное управление идентификацией и разрешениями упрощает процесс управления доступом, облегчает разработку и внедрение унифицированных стандартов разрешений на предприятии, что снижает риски безопасности, вызванные неправильным назначением разрешений.
Унифицированный контроль безопасности. В мультиаккаунтной среде идентификация, обработка и анализ событий безопасности и рисков, а также реагирование на события и их обработка осуществляются централизованно. Унифицированный контроль безопасности снижает рабочую нагрузку, связанную с контролем безопасности, и облегчает разработку и внедрение единых правил безопасности на предприятии. Для внедрения этих правил необходимо, чтобы облачные сервисы безопасности поддерживали унифицированное управление безопасностью и обеспечивали контроль над множеством учетных записей.
для Dev & Test