위임된 권한 전략 개발
이 문서는 개발자로서 애플리케이션에서 사용 권한을 관리하는 최상의 방법을 구현하고 제로 트러스트 원칙을 사용하여 개발하는 데 도움이 됩니다. 리소스에 액세스하기 위한 권한 획득에 설명된 대로 위임된 권한은 위임된 액세스와 함께 사용되어 애플리케이션이 사용자를 대신하여 작동하여 사용자가 액세스할 수 있는 항목에만 액세스할 수 있도록 합니다. 애플리케이션 사용 권한은 애플리케이션이 사용 권한이 연결된 데이터에 액세스할 수 있도록 직접 액세스와 함께 사용됩니다. 서비스 주체의 관리자 및 소유자만 애플리케이션 권한에 동의할 수 있습니다.
권한 및 동의 모델은 주로 애플리케이션을 참조합니다. 권한 및 동의 프로세스는 사용자가 수행할 수 있는 작업을 제어할 수 없습니다. 애플리케이션에서 수행할 수 있는 작업을 제어합니다.
다음 벤 다이어그램을 참조하세요. 위임된 권한을 사용하면 사용자가 수행할 수 있는 작업과 애플리케이션에서 수행할 수 있는 작업 간에 교차가 있습니다. 해당 교집합은 애플리케이션이 바인딩되는 유효 권한입니다. 위임된 권한을 사용할 때마다 유효한 사용 권한이 바인딩됩니다.
예를 들어 앱 앞에 사용자가 있는 애플리케이션은 테넌트의 모든 사용자 프로필을 업데이트할 수 있는 권한을 얻습니다. 그렇다고 해서 애플리케이션을 실행하는 모든 사용자가 다른 사람의 프로필을 업데이트할 수 있는 것은 아닙니다. 관리자가 애플리케이션 User.ReadWrite.All을 부여하기로 결정한 경우 사용자 프로필을 업데이트할 때 애플리케이션이 올바른 작업을 수행하고 있다고 믿습니다. 앱에서 변경 내용을 기록하고 정보를 적절하게 보호할 수 있습니다. 관리자는 사용자에 대한 것이 아니라 애플리케이션에 대한 가치 판단을 내린다.
최소 권한 접근 방식
API는 복잡할 수 있습니다. 단순 API에는 많은 작업이 없을 수 있습니다. Microsoft Graph와 같은 복잡한 API는 애플리케이션에서 사용할 수 있는 많은 요청을 캡슐화합니다. 애플리케이션이 읽을 권리가 있다고 해서 업데이트할 권리가 있어야 한다는 의미는 아닙니다. 예를 들어 Microsoft Graph에는 수천 대의 API가 있습니다. 사용자의 프로필을 읽을 수 있는 권한이 있다고 해서 모든 OneDrive 파일을 삭제할 수 있는 권한도 있어야 하는 이유가 없습니다.
개발자는 다음을 수행해야 합니다.
- 앱이 호출하는 API를 알고 있습니다.
- API 설명서 및 API에 필요한 사용 권한을 이해합니다.
- 최소 사용 권한을 사용하여 작업을 수행합니다.
API는 종종 조직 데이터 저장소에 대한 액세스를 제공하고 해당 데이터에 액세스하려는 공격자의 관심을 끌 수 있습니다.
요청하는 권한을 평가하여 작업을 완료하기 위해 절대 최소 권한 집합을 찾는지 확인합니다. 더 높은 권한 권한을 요청하지 않습니다. 대신 Microsoft Graph와 같은 API에서 제공하는 많은 권한을 신중하게 처리합니다. 요구 사항을 해결하기 위해 최소 사용 권한을 찾아 사용합니다. 사용자의 프로필을 업데이트하는 코드를 작성하지 않으면 애플리케이션에 대해 요청하지 않습니다. 사용자 및 그룹에만 액세스하는 경우 디렉터리의 다른 정보에 대한 액세스를 요청하지 않습니다. 사용자 전자 메일에 액세스하는 코드를 작성하지 않는 경우 사용자 전자 메일을 관리할 수 있는 권한을 요청하지 않습니다.
제로 트러스트 애플리케이션 개발:
- 애플리케이션의 의도와 필요한 사항을 정의합니다.
- 악의적인 행위자가 의도하지 않은 방식으로 앱을 손상시키고 사용할 수 없도록 합니다.
- 요구 사항을 정의하는 승인을 요청합니다(예: 사용자의 메일 읽기).
사용 권한 및 동의의 사용자 및 테넌트 관리자 역할
요청을 승인할 수 있는 사람 항상 권한 요청에 동의할 수 있는 관리자와 관리자가 아닌 일반 사용자라는 두 가지 범주로 구분됩니다. 그러나 테넌트 관리자는 관리자 동의가 필요한 권한 및 사용자가 동의할 수 있는 사용 권한에 대해 테넌트에 최종 말을 합니다.
API 디자이너에서 권한에 대한 관리자 동의가 필요한 경우 해당 권한에는 항상 관리자 동의가 필요합니다. 테넌트 관리자는 이를 재정의할 수 없으며 사용자 동의만 필요합니다.
API 디자이너가 사용자 동의가 필요한 권한을 정의하는 경우 테넌트 관리자는 API 디자이너의 사용자 동의 제안을 재정의할 수 있습니다. 테넌트 관리자는 테넌트에서 "큰 스위치"를 사용하여 이 작업을 수행할 수 있습니다. 모든 작업에는 관리자 동의가 필요합니다. 권한 및 동의 관리를 사용하여 보다 세분화된 방식으로 사용자 동의를 재정의할 수 있습니다. 예를 들어 사용자가 확인된 게시자의 사용자 동의 요청에 동의하도록 허용할 수 있지만 다른 게시 자는 동의할 수 없습니다. 또 다른 예제에서는 사용자를 로그인하고 프로필을 읽을 수 User.Read 있지만 메일 또는 파일에 대한 권한을 요청하는 앱에 대한 관리자 동의가 필요할 수 있습니다.
API 디자이너는 제안을 하지만 테넌트 관리자는 최종 말을 합니다. 따라서 개발자는 앱에 관리자 동의가 필요한 시기를 항상 알지 못합니다. 이를 계획하고 디자인하는 것이 좋지만 토큰 요청을 할 때 어떤 이유로든 거부될 수 있습니다. 코드에서는 고객 또는 사용자가 애플리케이션을 실행하는 테넌트 관리자가 권한에 관리자 동의가 필요한 시기를 결정하므로 토큰을 가져오지 않도록 정상적으로 처리해야 합니다.
JavaScript MSAL 사용 예제
이 예제의 인증의 경우 MSAL(JavaScript Microsoft 인증 라이브러리)을 사용하여 브라우저에서 모든 앱 논리가 실행되는 SPA(단일 페이지 애플리케이션)에서 사용자를 로그인합니다.
관련 빠른 시작 문서에서 코드 샘플을 다운로드하고 실행할 수 있습니다. JavaScript SPA(단일 페이지 애플리케이션)가 PKCE(Proof Key for Code Exchange)와 함께 권한 부여 코드 흐름을 사용하여 사용자를 로그인하고 Microsoft Graph를 호출하는 방법을 보여 줍니다. 코드 샘플에서는 Microsoft Graph API 또는 모든 웹 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);
});
}
앱은 표시 이름 또는 사용자 ID와 같은 사용자에 대한 정보를 가져올 수 있습니다. 다음으로 앱은 MSAL 라이브러리 전체에서 사용하는 패턴에 따라 Microsoft Graph에서 사용자의 전체 프로필을 읽을 수 있는 권한 부여가 필요합니다.
아래 예제 코드와 같이 앱은 호출 AcquireTokenSilent하여 권한 부여를 시도합니다. Microsoft Entra ID가 사용자와 상호 작용하지 않고 토큰을 발급할 수 있는 경우 앱이 사용자를 AcquireTokenSilent 대신하여 Microsoft Graph에 액세스하는 데 필요한 토큰을 반환합니다.
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 ID는 사용자와 상호 작용하지 않고 토큰을 발급할 수 없는 경우가 많습니다(예: 사용자가 암호를 변경했거나 동의를 부여하지 않음). 따라서 AcquireTokenSilent 사용자 상호 작용이 필요한 애플리케이션에 오류를 다시 보냅니다. 앱에서 오류를 받으면 다시 호출 AcquireTokenPopup합니다.
이 시점에서 Microsoft Entra ID는 사용자를 인증하고 앱이 사용자를 대신하여 작동하도록 권한을 부여할 수 있도록 사용자와 대화를 나눴습니다(예: MFA를 수행하고 암호를 제공하고 동의를 부여). 그런 다음 앱이 앞으로 이동하는 데 필요한 토큰을 가져옵니다.
제로 트러스트 기업 여정의 주요 단계는 사용자 ID 및 암호 대신 더 강력한 인증 방법을 채택하는 것입니다. 앞의 예제 코드는 엔터프라이즈가 선택하는 보다 강력한 인증 방법으로 이동할 수 있게 해줍니다. 예를 들어 다단계 인증, FIDO2 키를 사용한 완전 암호 없는 Microsoft Authenticator.
다음 단계
- 리소스에 액세스하기 위한 권한 부여를 획득하면 애플리케이션에 대한 리소스 액세스 권한을 획득할 때 제로 트러스트 가장 잘 확인하는 방법을 이해하는 데 도움이 됩니다.
- 애플리케이션 사용 권한 전략을 개발하면 자격 증명 관리에 대한 애플리케이션 사용 권한 접근 방식을 결정하는 데 도움이 됩니다.
- 토큰 사용자 지정은 Microsoft Entra 토큰에서 받을 수 있는 정보를 설명합니다. 최소 권한으로 애플리케이션 제로 트러스트 보안을 강화하면서 유연성과 제어를 향상시키기 위해 토큰을 사용자 지정하는 방법을 설명합니다.
- 토큰 에서 그룹 클레임 및 앱 역할을 구성하면 앱 역할 정의를 사용하여 앱을 구성하고 앱 역할에 보안 그룹을 할당하는 방법을 보여 줍니다. 이러한 방법은 최소한의 권한으로 애플리케이션 제로 트러스트 보안을 강화하면서 유연성과 제어를 개선하는 데 도움이 됩니다.
- API Protection은 등록을 통해 API를 보호하고, 사용 권한 및 동의를 정의하고, 제로 트러스트 목표를 달성하기 위해 액세스를 적용하는 모범 사례를 설명합니다.
- 다른 API에서 API를 호출하면 다른 API를 호출하고 사용자를 대신하여 작업할 때 애플리케이션을 안전하게 개발해야 하는 API가 하나 있는 경우 제로 트러스트 수 있습니다.
- 권한 부여 모범 사례는 애플리케이션에 대한 최상의 권한 부여, 권한 및 동의 모델을 구현하는 데 도움이 됩니다.
- 애플리케이션 개발 수명 주기에서 제로 트러스트 ID 및 액세스 관리 개발 모범 사례를 사용하여 보안 애플리케이션을 만듭니다.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기