Разработка стратегии делегированных разрешений

Эта статья поможет вам, как разработчику, реализовать оптимальный подход к управлению разрешениями в приложении и разработке с помощью принципов нулевого доверия. Как описано в разделе "Получение авторизации для доступа к ресурсам", делегированные разрешения используются с делегированным доступом, чтобы разрешить приложению действовать от имени пользователя, получая доступ только к тому, к чему может получить доступ пользователь. Разрешения приложения используются с прямым доступом для предоставления приложению доступа к любым данным, с которым связано разрешение. Только администраторы и владельцы субъектов-служб могут согласиться на разрешения приложения.

Модели разрешений и согласия относятся в основном к приложению. Процесс разрешения и согласия не имеет контроля над тем, что может сделать пользователь. Он определяет, какие действия разрешено выполнять приложение.

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

Например, приложение с пользователями перед приложением получает разрешение на обновление профиля каждого пользователя в клиенте. Это не означает, что любой пользователь, на котором запущено приложение, может обновить профиль любого другого пользователя. Если администратор решит предоставить приложение User.ReadWrite.All, то они считают, что приложение выполняет правильные действия при обновлении профиля пользователей. Ваше приложение может записывать изменения и правильно защищать информацию. Администратор принимает решение о приложении, а не о пользователе.

Минимальный подход к привилегиям

API могут быть сложными. Простые API могут не иметь большого количества операций. Сложные API, такие как Microsoft Graph, инкапсулируют множество запросов, которые может потребоваться использовать приложение. Просто потому, что приложение имеет право на чтение, не означает, что оно должно иметь право на обновление. Например, в Microsoft Graph есть тысячи API. Только так как у вас есть разрешение на чтение профиля пользователя, нет причин, почему у вас также должно быть разрешение на удаление всех своих файлов OneDrive.

Разработчик должен:

• знать, какие API вызывает приложение.
• ознакомьтесь с документацией по API и какими разрешениями требуется API.
• используйте наименьшее возможное разрешение для выполнения задач.

API часто предоставляют доступ к хранилищам данных организации и привлекают внимание злоумышленников, желающих получить доступ к этим данным.

Оцените запрашиваемые разрешения с целью убедиться в том, что вы просите о предоставлении минимально возможного набора привилегий, необходимого для выполнения задания. Избегайте запроса разрешений с более высоким уровнем привилегий; Вместо этого тщательно проработайте большое количество разрешений, предоставляемых API, таких как Microsoft Graph. Найдите и используйте минимальные разрешения для решения ваших потребностей. Если вы не пишете код для обновления профиля пользователя, вы не запрашиваете его для приложения. Если вы обращаетесь только к пользователям и группам, вы не запрашиваете доступ к другим сведениям в каталоге. Вы не запрашиваете разрешение на управление электронной почтой пользователя, если вы не пишете код, который обращается к электронной почте пользователя.

В разработке приложений нулевого доверия:

• Определите намерение приложения и его потребности.
• Убедитесь, что плохие субъекты не могут компрометации и использовать приложение таким образом, что вы не намеревались.
• Выполните запросы на утверждение, в котором определяются ваши требования (например, чтение почты пользователя).

Роли администратора пользователей и клиентов в разрешениях и согласии

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

Если конструктор API требует согласия администратора для разрешения, это разрешение всегда требует согласия администратора. Администратор клиента не может переуручить это и требовать только согласия пользователя.

Когда конструктор API определяет разрешения, требующие согласия пользователя, администратор клиента может переопределит предложения согласия пользователя конструктора API. Администраторы клиентов могут сделать это с помощью "большого коммутатора" в клиенте: все требует согласия администратора. Они могут переуручить согласие пользователя более детально с разрешениями и управлением согласием. Например, пользователи могут разрешить пользователям предоставлять согласие на запросы согласия пользователей от проверенных издателей, но не от других издателей. В другом примере они могут разрешить User.Read вход пользователя и читать свой профиль, но требовать согласия администратора приложениям, которые запрашивают разрешение на почту или файлы.

Разработчики API делают свои предложения, но администраторы клиентов имеют последнее слово. Таким образом, как разработчик, вы не всегда знаете, когда ваше приложение требует согласия администратора. Это приятно планировать и разрабатывать вокруг этого, но помните, когда вы делаете запрос токена, это может быть отклонено по любой причине. В коде необходимо корректно обрабатывать не получать маркер, так как администраторы клиента, в которых клиенты или пользователи работают с приложением, решают, когда разрешения требуют согласия администратора.

Пример использования JAVAScript MSAL

Для проверки подлинности в этом примере используется библиотека проверки подлинности Microsoft JavaScript (MSAL) для входа пользователя в одностраничное приложение (SPA), где выполняется все логика приложения из браузера.

Из связанной статьи краткого руководства вы можете скачать и запустить пример кода. В нем показано, как одностраничные приложения JavaScript могут входить в систему пользователей и вызывать Microsoft Graph с помощью потока кода авторизации с помощью ключа проверки подлинности для Exchange кода (PKCE). В примере кода показано, как получить маркер доступа для вызова API Microsoft Graph или любого веб-API.

Как показано в следующем примере кода, вы создаете экземпляр общедоступного клиента, так как приложение, которое работает полностью в браузере, должно быть общедоступным клиентом. Пользователь может получить свои руки на внутренних элементах приложения, когда код находится в браузере.

// Create the main myMSALObj instance
// configuration parameters are located at authConfig.js
const myMSALObj = new msal.PublicClientApplication(msalConfig);

Затем вы используете нашу библиотеку MSAL. В MSAL JavaScript существует определенный API для входа. В браузере есть два API, использующих определенные возможности. Один из них — войти с помощью всплывающего окна; Другой — войти с помощью интерфейса перенаправления браузера.

Как показано в следующем примере кода, всплывающее окно входа обрабатывает проверку подлинности, которую пользователь должен выполнить путем вызова signIn функции.

function signIn() {

    /**
     * You can pass a custom request object. This overrides the initial configuration. For more information, visit:
     * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/request-response-object.md#request
     */

    myMSALObj.loginPopup(loginRequest)
        .then(handleResponse)
        .catch(error => {
            console.error(error);
        });
}

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

Как показано в приведенном ниже примере кода, приложение пытается получить авторизацию путем вызова AcquireTokenSilent. Если идентификатор Microsoft Entra может выдавать маркер без взаимодействия с пользователем, то AcquireTokenSilent возвращает маркер, который приложение должно получить от имени пользователя.

function getTokenPopup(request) {

    /**
     * See here for more info on account retrieval: 
     * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-common/docs/Accounts.md
     */
    request.account = myMSALObj.getAccountByUsername(username);
    
    return myMSALObj.`AcquireTokenSilent`(request)
        .catch(error => {
            console.warn("silent token acquisition fails. acquiring token using popup");
            if (error instanceof msal.InteractionRequiredAuthError) {
                // fallback to interaction when silent call fails
                return myMSALObj.`AcquireTokenPopup`(request)
                    .then(tokenResponse => {
                        console.log(tokenResponse);
                        return tokenResponse;
                    }).catch(error => {
                        console.error(error);
                    });
            } else {
                console.warn(error);
            }
    });
}

Однако часто идентификатор Microsoft Entra не может выдавать маркер без взаимодействия с пользователем (например, пользователь изменил пароль или не предоставил согласие). AcquireTokenSilent Поэтому отправляет ошибку в приложение, требующее взаимодействия с пользователем. Когда приложение получает сообщение об ошибке, вы вернеесь к вызову AcquireTokenPopup.

На этом этапе идентификатор Microsoft Entra id имеет беседу с пользователем, чтобы они могли пройти проверку подлинности пользователя и авторизовать приложение, чтобы действовать от имени пользователя (например, сделать MFA, указать свой пароль, предоставить согласие). Затем приложение получает маркер, который необходимо переместить вперед.

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

Следующие шаги

• Получение авторизации для доступа к ресурсам помогает понять, как лучше всего обеспечить нулевое доверие при получении разрешений доступа к ресурсам для приложения.
• Разработка стратегии разрешений приложений помогает решить вопрос о подходе приложений к управлению учетными данными.
• Настройка маркеров описывает сведения, которые можно получить в токенах Microsoft Entra. В нем объясняется, как настроить маркеры для повышения гибкости и контроля при увеличении безопасности нулевого доверия приложений с минимальными привилегиями.
• Настройка утверждений групп и ролей приложений в маркерах показывает, как настроить приложения с определениями ролей приложения и назначить группы безопасности ролям приложений. Эти методы помогают повысить гибкость и контроль при увеличении безопасности нулевого доверия приложений с минимальными привилегиями.
• Защита API описывает рекомендации по защите API путем регистрации, определения разрешений и согласия и принудительного доступа к достижению целей нулевого доверия.
• Вызов API из другого API помогает обеспечить нулевое доверие, если у вас есть один API, который должен вызывать другой API и безопасно разрабатывать приложение при его работе от имени пользователя.
• Рекомендации по авторизации помогут реализовать лучшие модели авторизации, разрешения и согласия для приложений.
• Используйте рекомендации по разработке удостоверений и управления доступом в жизненном цикле разработки приложений для создания безопасных приложений.