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

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

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

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

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

Например, приложение с пользователями перед приложением получает разрешение на обновление профиля каждого пользователя в клиенте. Это не означает, что любой пользователь, на котором запущено приложение, может обновить профиль любого другого пользователя. Если администратор решит предоставить приложение 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 below. This will override 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 и безопасно разрабатывать приложение при работе от имени пользователя.
• Рекомендации по авторизации помогут реализовать лучшие модели авторизации, разрешения и согласия для приложений.
• Используйте рекомендации по разработке удостоверений и управления доступом в жизненном цикле разработки приложений для создания безопасных приложений.