Azure AD и приложения: от создания до повышения безопасности

Во второй статье об Azure AD и приложениях мы повысим безопасность приложения, созданного в первой статье этой серии. Мы введем условный доступ и самообслуживание с помощью утверждений, но, поскольку мы не хотим давать доступ к приложению навсегда, мы реализуем , где мы можем проверять и оставлять доступ к приложению только действительным пользователям.
Azure AD и приложения: реализация условного доступа
Первый уровень защиты, представленный Azure AD Premium, который мы можем добавить в наше приложение Azure AD, — это функция условного доступа. Мы можем использовать эту функцию, щелкнув Azure Active Directory, Безопасность, а затем выбрав Условный доступ, что является традиционным способом.
Однако при управлении приложениями в Enterprise Application и выборе нужного приложения (в нашей статье мы собираемся использовать ) новый блейд содержит все свойства и функции данного приложения. У нас есть доступный элемент условного доступа, и у него есть особое свойство: он будет отображать только политики условного доступа, относящиеся к текущему приложению.
Мы можем использовать тот же интерфейс для создания нового условного доступа, как показано на изображении ниже. Отличие запуска из свойств приложения от традиционного способа в том, что при использовании первого приложение автоматически добавляется в правило.
В предыдущей статье мы представили использование группы для управления тем, кто имеет доступ к приложению, и группа была названа AP6-AzureApp-GitHub, поэтому мы можем воспользоваться этой схемой и использовать эту группу в условном доступе, как изображен на изображении ниже. Если вы не хотите волноваться, вы всегда можете оставить , особенно в случаях, когда пользователи добавляются непосредственно в права пользователей и групп приложения.
Примечание. У вас всегда есть возможность исключить ключевых пользователей, чтобы убедиться, что вы не заблокированы вне приложения. Например, в критически важных приложениях, таких как Azure Portal, очень важно исключить учетные записи для разбивания стекла. В сценарии приложения вы можете добавить тестового пользователя во время проверки или устранения неполадок.
Мы можем принудительно использовать многофакторную аутентификацию при доступе к этому приложению из-за пределов доверенных сетей. Таким образом мы применяем строгую аутентификацию для пользователей за пределами нашей организации. Тем не менее, в мастере обязательно выберите «Предоставить доступ» и «Требовать многофакторную аутентификацию» в разделе .
Результат после создания новой политики будет указан справа. Имейте в виду, что в этой колонке будут перечислены только политики условного доступа, относящиеся к рассматриваемому приложению. Чтобы просмотреть все , обязательно используйте элемент Azure AD Security Conditional Access.
Чтобы проверить, применяются ли политики условного доступа, или просто проверить процесс входа, мы всегда можем щелкнуть «Входы», и будут перечислены все запросы аутентификации, относящиеся к рассматриваемому приложению.
Внедрение самообслуживания
Мы можем реализовать возможности самообслуживания с помощью Azure, чтобы уменьшить нагрузку на вашу службу поддержки. В колонке свойств приложения щелкните элемент Самообслуживание.
В новом блейде нам нужно сначала разрешить пользователям запрашивать доступ к рассматриваемому приложению (пункт 1). Второй шаг — определить группу, в которую будут включены пользователи. В нашей статье это будет AP6-AzureApp-GitHub (пункт 2).
Администратор облака может потребовать утверждения перед назначением приложения. Щелкните Выбрать утверждающих и выберите пользователя из списка (пункт 4). Последний шаг (пункт 5) — определить, какую роль получит новый пользователь.
С точки зрения конечного пользователя процесс запроса доступа к приложению прост. Войдите на портал myapps.microsoft.com, нажмите «Добавить приложение».
Появится список предлагаемых приложений. Выберите нужное приложение и нажмите «Добавить». Новое диалоговое окно с вопросом будет отображаться. Нажмите Добавить. Если приложение требует утверждения, вы увидите следующее сообщение: . Нажмите OK и дождитесь завершения процесса утверждения на серверной части.
Утверждающий получит сообщение, содержащее всю информацию, чтобы решить, разрешено ли приложение для данного пользователя. Доступны два варианта: одобрить или отклонить. В случае одобрения программное обеспечение будет отображаться на портале для конечного пользователя.
Осуществление проверки
Используя функцию , мы можем просмотреть данное приложение и принять меры. Чтобы создать новый обзор, нажмите «Проверка доступа», а затем создайте «Новый обзор доступа».
В новой колонке назначьте имя проверке, укажите дату начала и периодичность, а также время завершения процесса проверки. Обязательно задайте область (только гостевые пользователи или все) и выберите .
Выберите (есть возможность самостоятельной проверки), и функция предоставит предложения. Мы можем применить эти предложения автоматически и принять меры, если рецензент не предпримет никаких действий.
У нас также есть некоторые дополнительные настройки, которые могут быть полезны для вашей организации, такие как рекомендации, требование причины для утверждения, почтовые уведомления и напоминания.
После того, как обзор доступа создан, мы можем щелкнуть по нему мы можем увидеть общий статус обзора. В этом же лезвии мы можем проверить (включая рекомендации), и некоторые настройки, которые можно изменить во время текущего обзора.
получит сообщение, информирующее его о проверке процесса рецензирования. Чтобы начать просмотр, просто нажмите «Начать просмотр».
будет перенаправлен на страницу «Мой доступ». Нажмите «Доступ к отзывам», и появится список всех отзывов, требующих внимания. Щелкните нужный .
На новой странице все участники будут перечислены с рекомендацией, и мы можем выбрать любого пользователя и выполнить действие: одобрить, отклонить или не знаю. Также сбросьте ранее принятые решения или примите рекомендации, предложенные функцией (пункт 1).
Примечание. Это представление аналогично при использовании портала Azure. Преимущество портала Azure заключается в том, что он создает отчет обо всех входах в систему каждого проверяемого участника и помогает анализировать, как рассматриваемый пользователь проходит проверку подлинности в приложении.
Когда период проверки закончится, настройки будут применены на основе решений, принятых во время проверки, и настроек, определенных на уровне .
Azure AD и приложения: снижение сложности, повышение безопасности
Внедрив эти функции безопасности, мы повысили уровень нашей безопасности, заставив человека (владельца) проверять, кто может получить доступ к приложению, и регулярно проверять пользователей, имеющих доступ к приложению.
Используя методы из этой статьи, мы можем увидеть несколько преимуществ традиционной ИТ-среды. Во-первых, мы возлагаем ответственность на владельца приложения, и мы можем уменьшить сложность, предоставив пользователям доступ только к тем приложениям, доступ к которым им необходим для выполнения их работы. Во-вторых, мы снижаем сложность, поскольку теперь пользователи могут добавлять свои приложения, к которым им нужен доступ, без запросов в службу поддержки. В-третьих, все это безопасно и использует корпоративные стандарты, которые можно последовательно применять в нескольких других приложениях.