제로 트러스트 대한 사용자 인증

  • 아티클

이 문서는 개발자가 제로 트러스트 애플리케이션 개발에서 애플리케이션 사용자를 인증하기 위한 모범 사례를 학습하는 데 도움이 됩니다. 항상 최소 권한의 제로 트러스트 원칙을 사용하여 애플리케이션 보안을 강화하고 명시적으로 확인합니다.

사용자 인증의 ID 토큰

사용자가 사용자 이름과 암호를 수집하는 대신 앱에 인증해야 하는 경우 애플리케이션에서 ID(ID) 토큰을 요청할 수 있습니다. Microsoft ID 플랫폼 통해 사용자를 인증하면 애플리케이션에서 사용자 자격 증명을 유지할 때 발생하는 보안 위험을 방지할 수 있습니다. ID 토큰을 요청할 때 잘못된 행위자가 애플리케이션을 위반하거나 손상하는 경우 앱에는 사용자 이름과 해당 암호가 없습니다.

Microsoft ID 플랫폼 ID 토큰은 ID 토큰을 JWT(JSON 웹 토큰)로 지정하는 OIDC(OpenID 커넥트) 표준의 일부입니다. JWT long 문자열은 다음 세 가지 구성 요소로 구성됩니다.

  1. 헤더 클레임입니다. ID 토큰에 있는 헤더 클레임에는 (형식 클레임), alg (토큰 서명 알고리즘) 및 kid (토큰의 서명 유효성을 검사하기 위한 공개 키의 지문)이 포함 typ 됩니다.
  2. 페이로드 클레임. 페이로드 또는 본문(JSON 웹 토큰의 중간 부분)에는 일련의 이름 특성 쌍이 포함됩니다. 표준에는 토큰(또는 대상 그룹 클레임 iss )을 발급한 애플리케이션으로 가는 (발급자 이름)이 있는 클레임이 aud있어야 합니다.
  3. 서명 Microsoft Entra ID는 앱이 토큰이 수정되지 않았으며 신뢰할 수 있는지 확인하는 데 사용할 수 있는 토큰 서명을 생성합니다.

다음 ID 토큰 예제에서는 사용자에 대한 정보를 표시하고 애플리케이션을 사용하기 위한 인증을 확인합니다.

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "1LTMzakihiRla_8z2BEJVXeWMqo"
}.
{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/3338040d-6c67-4c5b-b112-36a304b66dad/v2.0",
  "aud": "6cb04018-a3f5-46a7-b995-940c78f5aef3",
  "exp": 1536361411,
  "iat": 1536274711,
  "nbf": 1536274711,
  "sub": "AAAAAAAAAAAAAAAAAAAAAIkzqFVrSaSaFHy782bbtaQ",
  "name": "Abe Lincoln",
  "preferred_username": "AbeLi@microsoft.com",
  "oid": "00000000-0000-0000-66f3-3332eca7ea81",
  "tid": "3338040d-6c67-4c5b-b112-36a304b66dad",
}.
.[Signature]

액세스 관리의 ID 토큰

애플리케이션(클라이언트) ID를 받으려면 Microsoft ID 플랫폼 앱을 등록합니다. 앱의 클라이언트 ID와 일치하는 대상 그룹 클레임(aud)이 있는 토큰을 받으면 토큰에서 식별된 사용자가 앱에 인증됩니다. IT 관리자는 테넌트에 있는 모든 사용자가 앱을 사용하도록 허용할 수 있습니다. 사용자가 멤버인 그룹이 앱을 사용하도록 허용할 수 있습니다.

대상 그룹 클레임이 앱의 클라이언트 ID와 다른 토큰을 받으면 토큰을 즉시 거부합니다. 사용자가 다른 앱에 로그인했기 때문에 앱에 인증되지 않습니다. 항상 사용자에게 앱을 사용할 수 있는 권한이 있는지 확인합니다.

이러한 클레임 세부 정보는 사용자 인증에서 중요합니다.

  • JSON 웹 토큰은 만료될 때까지 유효합니다. (만료) 클레임은 exp 토큰이 만료되는 시기를 알려줍니다. 현재 시간이 클레임의 시간 exp 이전인 경우 토큰이 유효합니다.
  • (이전이 아닌) 클레임에 nbf 지정된 시간 전에 사용자를 인증된 것으로 간주하지 마세요. nbf 토큰의 시간과 exp 시간은 토큰의 유효한 수명을 정의합니다. 만료 시간이 임박한 경우 새 ID 토큰을 가져와야 합니다.
  • sub (주체 클레임)은 애플리케이션 사용자의 고유 식별자입니다. 동일한 사용자가 다른 앱에 대해 다른 sub 클레임을 가지고 있습니다. 데이터를 저장하여 사용자에게 다시 연결하고 공격자가 해당 연결을 만들지 못하게 하려면 주체 클레임을 사용합니다. 사용자의 Microsoft Entra ID를 노출하지 않으므로 데이터를 사용자에게 연결하는 가장 개인적인 방법입니다. 클레임은 sub 변경할 수 없습니다.
  • 여러 애플리케이션에서 정보를 공유하려는 경우 사용자에게 고유한 테넌트 ID(tid) 및 개체 ID(oid) 클레임의 조합을 사용합니다. 결합된 테넌트 ID와 개체 ID는 변경할 수 없습니다.
  • 개인의 ID, suboid클레임 및 tid 클레임에 어떤 일이 발생하든기본 변경할 수 없습니다. 사용자에 대한 모든 항목은 변경될 수 있으며 주체 또는 결합 tid 된 oid 클레임에 따라 데이터를 식별하지 않아도 됩니다.

OIDC를 사용한 인증

사용자 인증을 시연하기 위해 OIDC를 사용하여 사용자를 인증하는 애플리케이션을 살펴보겠습니다. SAML(Security Assertion Markup Language) 또는 WS-Federation을 사용하는 앱에는 동일한 원칙이 적용됩니다.

애플리케이션이 Microsoft ID 플랫폼 ID 토큰을 요청할 때 앱이 사용자를 인증합니다. 워크로드(사용자가 없지만 서비스, 백그라운드 프로세스, 디먼으로 실행되는 애플리케이션)는 이 단계를 건너뜁니다.

이 토큰을 먼저 자동으로 요청해야 합니다. MSAL(Microsoft 인증 라이브러리)에서 토큰을 자동으로 획득하려면 앱이 AcquireTokenSilent 이 메서드로 시작할 수 있습니다. 앱이 사용자를 방해하지 않고 인증할 수 있는 경우 요청된 ID 토큰을 받습니다.

Microsoft ID 플랫폼 사용자와 상호 작용하지 않고 요청을 완료할 수 없는 경우 앱이 MSAL AcquireTokenInteractive 메서드로 대체되어야 합니다. 토큰을 대화형으로 획득하려면 할 일기본 아래 https://login.microsoftonline.com 의 주소로 웹 화면을 열어 요청을 수행합니다.

이 웹 화면에서 사용자는 Microsoft ID 플랫폼 비공개 대화를 합니다. 앱은 이 대화를 볼 수 없으며 대화를 제어할 수도 없습니다. Microsoft ID 플랫폼 사용자 ID 및 암호, MFA(다단계 인증), 암호 없는 인증 또는 IT 관리자 또는 사용자가 구성한 기타 인증 상호 작용을 요청할 수 있습니다.

사용자가 필요한 인증 단계를 수행한 후 애플리케이션에서 ID 토큰을 받게 됩니다. 앱이 토큰을 받으면 Microsoft ID 플랫폼 사용자를 인증했음을 확신할 수 있습니다. 앱이 ID 토큰을 받지 못하면 Microsoft ID 플랫폼 사용자를 인증하지 않았습니다. 인증되지 않은 사용자가 앱의 보안 영역으로 계속 이동할 수 없도록 합니다.

애플리케이션은 Microsoft Entra ID에서 ID 토큰을 받은 후 사용자에 대한 세션을 만드는 것이 가장 좋습니다. 앱이 수신하는 ID 토큰에서 Unix 타임스탬프가 있는 만료(exp) 클레임입니다. 이 타임스탬프는 앱이 처리를 위해 JWT를 수락하지 않아야 하는 만료 시간 또는 이후를 지정합니다. 이 토큰 만료 시간을 사용하여 사용자 세션의 수명을 구동합니다. 클레임은 exp 앱 앞에 명시적으로 확인된 사용자를 적절한 권한과 적절한 시간 동안 유지하는 데 중요한 역할을 합니다.

Single Sign-On 지원

SSO(Single Sign-On ) 인증을 통해 사용자는 하나의 자격 증명 집합으로 여러 독립 소프트웨어 시스템에 로그인할 수 있습니다. SSO를 사용하면 애플리케이션 개발자가 사용자가 모든 애플리케이션에 개별적으로 반복적으로 로그인할 필요가 없습니다. SSO의 핵심에서 개발자는 사용자의 디바이스에 있는 모든 애플리케이션이 사용자를 인증하는 웹 화면을 공유하도록 합니다. 인증 드라이브 SSO가 성공한 후 웹 화면의 아티팩트(예: 세션 상태 및 쿠키)입니다.

다음 다이어그램에 나와 있는 것처럼 공유 웹 화면의 가장 간단한 사용 사례는 웹 브라우저(예: Microsoft Edge, Google Chrome, Firefox, Safari)에서 실행되는 앱입니다. 브라우저 탭은 SSO 상태를 공유합니다.

다이어그램은 앱이 브라우저에서 실행되는 공유 웹 화면 시나리오를 보여 줍니다.

Microsoft ID 플랫폼 사용자가 동일한 디바이스에서 서로 다른 브라우저를 열지 않는 한 특정 브라우저에서 SSO 상태를 관리합니다. Windows 10 이상에서는 Microsoft ID 플랫폼 기본적으로 브라우저 SSO Microsoft Edge를 지원합니다. 사용자가 Windows에 로그인하면 Google Chrome(Windows 10 계정 확장을 통해)과 Mozilla Firefox v91+(브라우저 설정을 통해)의 숙박 시설을 통해 각 브라우저가 Windows 자체의 SSO 상태를 공유할 수 있습니다.

다음 다이어그램에 표시된 것처럼 네이티브 애플리케이션 사용 사례는 더 복잡합니다.

다이어그램은 SSO가 없는 포함된 브라우저의 복잡한 네이티브 애플리케이션 사용 사례를 보여 줍니다.

인증 브로커 접근 방식

일반적인 패턴은 각 네이티브 앱이 SSO에 참여하지 못하도록 하는 자체 포함된 WebView를 갖는 것입니다. 이 시나리오를 해결하기 위해 Microsoft Entra ID는 다음 다이어그램에 설명된 대로 네이티브 애플리케이션에 인증 브로커(인증 브로커) 접근 방식을 사용합니다.

다이어그램은 네이티브 애플리케이션에 인증 브로커를 사용하는 방법을 보여 줍니다.

인증 브로커가 있는 경우 애플리케이션은 직접 Microsoft ID 플랫폼 대신 브로커에 인증 요청을 보냅니다. 이러한 방식으로 broker는 디바이스의 모든 인증에 대한 공유 화면이 됩니다.

인증 브로커는 공유 표면을 제공하는 것 외에도 다른 이점을 제공합니다. 제로 트러스트 채택할 때 엔터프라이즈는 엔터프라이즈 관리 디바이스에서만 애플리케이션을 실행하려고 할 수 있습니다. 엔터프라이즈 디바이스 관리의 예로는 전체 MDM(모바일 장치 관리) 및 사용자가 MAM(모바일 애플리케이션 관리)에 참여하는 자체 디바이스를 가져오는 시나리오가 있습니다.

기본적으로 OS(기본 운영 체제)는 브라우저를 격리합니다. 개발자는 디바이스 세부 정보에 대한 모든 권한을 갖기 위해 OS와 긴밀한 연결이 필요합니다. Windows에서 인증 브로커는 WAM(Windows 웹 계정 관리자 )입니다. 다른 디바이스에서 인증 브로커는 Microsoft Authenticator 앱(iOS 또는 Android를 실행하는 디바이스용) 또는 회사 포털 앱(Android를 실행하는 디바이스의 경우)입니다. 애플리케이션은 MSAL을 사용하여 인증 브로커에 액세스합니다. Windows에서 앱은 MSAL 없이 WAM에 액세스할 수 있습니다. 그러나 MSAL은 앱이 인증 브로커(특히 유니버설 Windows 플랫폼 앱이 아닌 앱)에 액세스하는 가장 쉬운 방법입니다.

인증 브로커는 Microsoft Entra ID와 함께 작동하여 사용자가 여러 번 인증할 필요가 낮아지도록 PRT(기본 새로 고침 토큰)를 활용합니다. PRT는 사용자가 관리되는 디바이스에 있는지 여부를 확인할 수 있습니다. Microsoft Entra ID는 현재 널리 사용되는 전달자 토큰보다 더 안전한 옵션인 소유 증명 토큰을 도입하므로 인증 브로커가 필요합니다.

다음 단계