Вопросы на собеседовании: Azure-инженер

Регион Azure является местом развёртывания внутри географии Azure, а парный регион служит назначенным партнёром для восстановления платформы там, где применяется парность.

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

Зоны доступности, это физически отдельные группы дата-центров внутри одного региона Azure, которые помогают пережить отказ дата-центра.

• У каждой зоны независимые электропитание, охлаждение и сеть, а между зонами региона сохраняется связь с низкой задержкой.
• Зональный ресурс закреплён за одной зоной, а сервис с зональным резервированием распределяется или реплицируется между зонами.
• Я размещу резервные экземпляры VM в разных зонах и проверю поддержку зон всеми нужными сервисами и SKU в выбранном регионе.

Ресурс входит в одну группу ресурсов, а группа ресурсов входит в одну подписку.

• Подписка служит границей биллинга, квот и доступа и связана с тенантом Microsoft Entra.
• Группа ресурсов объединяет связанные ресурсы по жизненному циклу, хотя сами ресурсы могут работать в разных регионах Azure.
• RBAC и Azure Policy наследуются сверху вниз, поэтому удаление группы ресурсов нужно воспринимать как удаление всего её содержимого.

Плоскость управления ARM управляет ресурсами Azure, а плоскость данных сервиса работает с данными внутри уже развёрнутого ресурса.

• Создание учётной записи хранения или изменение её сетевых настроек, это операция плоскости управления через Azure Resource Manager.
• Загрузка блоба или запрос к базе Azure SQL, это операция плоскости данных через конечную точку конкретного сервиса.
• Права разделены, поэтому роль Contributor позволяет управлять учётной записью хранения, но не обязательно читать её блобы.

Microsoft защищает облачную платформу, а клиент отвечает за свои данные, удостоверения, доступ и конфигурацию нагрузки.

• Microsoft всегда отвечает за физические дата-центры, оборудование и базовую инфраструктуру хостов.
• Для Azure VM я по-прежнему обновляю гостевую ОС и защищаю приложение, а в Azure SQL больше обслуживания ОС и движка берёт на себя платформа.
• RBAC, сетевую доступность, параметры шифрования, резервные копии и мониторинг нужно настраивать, а не считать автоматически включёнными правильно.

Пользователь представляет человека, группа объединяет удостоверения, а субъект-служба представляет приложение или автоматизацию в тенанте.

• Пользователи входят интерактивно и могут быть созданы в облаке или синхронизированы из локального каталога.
• Группы позволяют выдать доступ к приложению или роль Azure сразу многим участникам вместо настройки каждого человека.
• Субъект-служба является локальным удостоверением приложения в тенанте и должен получать только необходимые нагрузке роли.

Управляемое удостоверение, это субъект-служба Microsoft Entra, жизненным циклом учётных данных которого Azure управляет для нагрузки.

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

Назначение роли Azure RBAC выдаёт субъекту роль в определённой области, а доступ наследуется дочерними областями.

• Основные области идут от группы управления к подписке, группе ресурсов и отдельному ресурсу.
• Назначение объединяет получателя доступа, роль с разрешёнными действиями и место применения этих действий.
• Я выбираю самую узкую встроенную роль и область, например Storage Blob Data Reader для одной учётной записи вместо Owner на подписке.

Azure Key Vault централизованно защищает секреты, криптографические ключи и сертификаты, а приложение должно обращаться к нему через управляемое удостоверение.

• Секреты хранят значения вроде строк подключения, ключи выполняют криптографические операции, а сертификаты включают материалы для их жизненного цикла.
• Аутентификация Microsoft Entra и Azure RBAC должны разрешать приложению только нужные операции, например чтение секретов конкретного хранилища.
• При необходимости я также ограничу сетевой доступ и сохраню возможности восстановления через soft delete и защиту от очистки.

MFA добавляет ещё одно подтверждение личности, а Conditional Access решает, разрешать ли доступ и требовать ли MFA или другой контроль.

• Политика Conditional Access оценивает пользователя, приложение, состояние устройства, расположение и риск входа.
• При совпадении условий она может потребовать MFA или соответствующее требованиям устройство либо заблокировать вход.
• Я сначала проверю политику в режиме report-only и исключу контролируемые аварийные учётные записи, чтобы не заблокировать всех администраторов.

Я выбираю частный непересекающийся CIDR-блок с запасом для текущих подсетей и будущего роста.

• CIDR вида 10.20.0.0/16 задаёт адресное пространство VNet, из которого подсетям выделяются меньшие диапазоны.
• В каждой подсети Azure резервирует пять IP-адресов, поэтому подсеть /29 не отдаёт ресурсам все восемь адресов.
• Сначала я проверяю планируемые пиринговые сети, VPN и ExpressRoute, потому что пересечение адресов мешает прямой маршрутизации между ними.

Подсеть, это непересекающаяся часть адресного пространства VNet для размещения и управления группой ресурсов.

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

NSG фильтрует входящий и исходящий трафик правилами с сохранением состояния, а сервисные теги представляют поддерживаемые Azure группы IP-диапазонов.

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

Пользовательский маршрут дополняет или переопределяет системные маршруты Azure и направляет подходящий трафик к выбранному следующему узлу.

• Таблица маршрутов сопоставляет префиксы адресов и поддерживает типы следующего узла `Virtual appliance`, `Virtual network gateway` и `None`.
• Тип `Virtual appliance` использует частный IP и может направлять трафик в управляемый Azure Firewall или стороннее Network Virtual Appliance, но сам Azure Firewall не является устройством.
• Таблица связывается с подсетью, а для трафика через сетевую функцию я проверяю пересылку IP и обратные маршруты.

Общедоступный IP Azure, это отдельно управляемый адресный ресурс, который выводит поддерживаемый фронтенд Azure в интернет.

• Его можно связать с фронтендом балансировщика, NAT Gateway, Application Gateway или сетевым интерфейсом VM.
• Статическое выделение сохраняет адрес за ресурсом, что важно для DNS-записей и внешних списков разрешённых адресов.
• Общедоступный IP даёт достижимость, а не защиту, поэтому доступ всё равно контролируют NSG, межсетевые экраны и аутентификация приложения.

Azure NAT Gateway даёт подсети масштабируемый и предсказуемый исходящий доступ в интернет через один или несколько статических общедоступных IP-адресов.

• Частные ресурсы проходят через преобразование исходных адресов без отдельного общедоступного IP на каждой VM.
• Шлюз подключается к подсети и получает приоритет для новых исходящих соединений поддерживаемых ресурсов этой подсети.
• Он не принимает незапрошенные входящие соединения, поэтому для входа нужны Load Balancer, Application Gateway или Bastion.

Azure Bastion предоставляет управляемый доступ по RDP и SSH к частным IP виртуальных машин без общедоступных IP на самих VM.

• Администратор подключается через портал Azure или поддерживаемый нативный клиент, а Bastion достигает цели внутри VNet.
• VM не приходится напрямую открывать в интернет порт RDP 3389 или SSH 22.
• Доступ всё равно нужно ограничить через Azure RBAC, учётные данные VM или вход Entra и подходящие сетевые правила.

Azure Private Link, это технология частного подключения, а частная конечная точка, это сетевой интерфейс с частным адресом VNet для связи с поддерживаемым сервисом через эту технологию.

• Клиенты отправляют трафик на частный IP по сети Microsoft вместо обращения к общедоступной конечной точке сервиса.
• Конечная точка создаётся в подсети и нацеливается на конкретный подресурс сервиса, например Blob учётной записи хранения.
• Я также проверю общедоступный сетевой доступ сервиса, потому что добавление частной точки само по себе может не отключить публичную.

Private DNS заставляет обычное имя сервиса разрешаться в адрес частной конечной точки для клиентов в подключённой VNet.

• Сервисы Azure используют зоны частного DNS вида privatelink.blob.core.windows.net для записей частных конечных точек.
• Связь зоны с VNet позволяет нагрузкам использовать стандартное имя сервиса, хотя DNS возвращает частный IP.
• Для локальных клиентов или собственного DNS я настраиваю пересылку либо Azure DNS Private Resolver, чтобы они получали тот же частный ответ.

Пиринг VNet даёт двум виртуальным сетям частную связь с низкой задержкой по магистрали Azure, но по умолчанию эта связь не транзитивна.

• Пиринговые VNet общаются по частным адресам, если их адресные пространства не пересекаются и правила безопасности разрешают трафик.
• Если VNet A связана пирингом с B, а B с C, сеть A не получает маршрут к C автоматически.
• В топологии hub-and-spoke для связи между лучами нужны явные пиринги или маршрутизация через шлюз, межсетевой экран либо виртуальное сетевое устройство.