다음을 통해 공유

개발자 모범 사례를 통한 복원력

  • 아티클

이 문서에서는 대규모 고객과 함께 작업한 경험을 활용할 수 있습니다. 서비스의 디자인 및 구현에 대해 이러한 권장 사항을 고려할 수 있습니다.

Microsoft 인증 라이브러리

MSAL(Microsoft 인증 라이브러리 ) 및 ASP.NET 위한 Microsoft ID 웹 인증 라이브러리는 애플리케이션에 대한 토큰 획득, 관리, 캐싱 및 새로 고침을 간소화합니다. 이러한 라이브러리는 애플리케이션 복원력을 향상시키는 기능을 포함하여 Microsoft ID를 지원하도록 최적화되어 있습니다.

개발자는 MSAL의 최신 릴리스를 채택하고 최신 상태를 유지할 수 있습니다. 애플리케이션에서 인증 및 권한 부여 복원력을 향상하는 방법을 참조하세요. 가능한 경우 사용자 고유의 인증 스택을 구현하지 마세요. 대신, 잘 설정된 라이브러리를 사용합니다.

디렉터리 읽기 및 쓰기 최적화

Azure AD B2C 디렉터리 서비스는 초당 읽기 비율이 높은 하루에 수십억 개의 인증을 지원합니다. 쓰기를 최적화하여 의존도를 최소화하고 복원력을 높입니다.

디렉터리 읽기 및 쓰기를 최적화하는 방법

  • 로그인 시 디렉터리에 함수를 쓰지 마세요. 사용자 지정 정책에서 사전 조건(if 절)없이 로그인 시 쓰기를 실행하지 마세요. 로그인 시 쓰기가 필요한 한 가지 사용 사례는 사용자 암호의 Just-In-Time 마이그레이션입니다. 로그인할 때마다 쓰기가 필요하지 않습니다. 사용자 경험의 전제 조건은 다음과 같습니다.

    <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> 
<Value>requiresMigration</Value>
...
<Precondition/>

  • 제한 이해: 디렉터리가 애플리케이션 및 테넌트 수준 제한 규칙을 구현합니다. 읽기/GET, 쓰기/POST, 업데이트/PUT 및 삭제/삭제 작업에는 더 많은 속도 제한이 있습니다. 각 작업에는 서로 다른 제한이 있습니다.

    • 로그인하는 동안 쓰기는 새 사용자에 대한 POST 또는 현재 사용자의 PUT에 속합니다.
    • 로그인할 때마다 사용자를 만들거나 업데이트하는 사용자 지정 정책은 애플리케이션 수준 PUT 또는 POST 속도 제한에 도달할 수 있습니다. Microsoft Entra ID 또는 Microsoft Graph를 통해 디렉터리 개체를 업데이트하는 경우에도 동일한 제한이 적용됩니다. 마찬가지로, 읽기를 검토하여 로그인할 때마다 읽기 수를 최소로 유지합니다.
    • 최대 부하를 예상하여 디렉터리 쓰기 속도를 예측하고 제한이 적용되지 않도록 합니다. 최대 트래픽 예측에는 등록, 로그인 및 MFA(다단계 인증)와 같은 작업에 대한 예상이 포함되어야 합니다. Azure AD B2C 시스템 및 애플리케이션에서 최대 트래픽을 테스트합니다. Azure AD B2C는 다운스트림 애플리케이션 또는 서비스가 제한되지 않을 때 제한 없이 부하를 처리할 수 있습니다.
    • 마이그레이션 타임라인을 이해하고 계획합니다. Microsoft Graph를 사용하여 사용자를 Azure AD B2C로 마이그레이션할 계획인 경우 애플리케이션 및 테넌트 제한을 고려하여 사용자 마이그레이션을 완료하는 시간을 계산합니다. 두 애플리케이션을 사용하여 사용자 만들기 작업 또는 스크립트를 분할하는 경우 애플리케이션당 제한을 사용할 수 있습니다. 테넌트당 임계값 미만으로 유지되는지 확인합니다.
    • 다른 애플리케이션에 대한 마이그레이션 작업의 영향을 이해합니다. 테넌트 수준에서 제한이 없고 라이브 애플리케이션에 대한 리소스 부족이 발생하지 않도록 다른 신뢰 애플리케이션에서 제공하는 라이브 트래픽을 고려합니다. 자세한 내용은 Microsoft Graph 제한 지침을 참조하세요.
    • 부하 테스트 샘플을 사용하여 등록과 로그인을 시뮬레이션합니다.
    • Azure AD B2C 서비스 제한 및 제한 사항에 대해 자세히 알아봅니다.

토큰 수명

Azure AD B2C 인증 서비스에서 새 등록 및 로그인을 완료할 수 없는 경우 로그인한 사용자에 대한 완화를 제공합니다. 구성을 사용하면 로그인한 사용자는 애플리케이션에서 로그아웃하거나 세션이 비활성 상태에서 시간이 초과될 때까지 중단 없이 애플리케이션을 사용할 수 있습니다.

비즈니스 요구 사항 및 최종 사용자 환경에 따라 웹 및 SPA(단일 페이지 애플리케이션)에 대한 토큰 새로 고침 빈도가 결정됩니다.

토큰 수명 연장

  • 웹 애플리케이션: 로그인 시 인증 토큰의 유효성을 검사하는 웹 애플리케이션의 경우 애플리케이션은 세션 유효성을 계속 확장하기 위해 세션 쿠키에 의존합니다. 사용자 활동에 따라 갱신되는 롤링 세션 시간을 구현하여 사용자가 로그인 상태를 유지할 수 있도록 합니다. 장기 토큰 발급 중단이 있는 경우 애플리케이션에서 일회성 구성으로 이러한 세션 시간을 늘릴 수 있습니다. 세션의 수명을 허용되는 최댓값으로 유지합니다.
  • SPA: SPA는 API를 호출하기 위해 액세스 토큰에 따라 달라질 수 있습니다. SPA의 경우 PKCE(코드 교환용 증명 키) 흐름과 함께 권한 부여 코드 흐름을 사용자가 애플리케이션을 계속 사용할 수 있도록 하는 옵션으로 사용하는 것이 좋습니다. SPA가 암시적 흐름을 사용하는 경우 PKCE를 사용하여 권한 부여 코드 흐름으로 마이그레이션하는 것이 좋습니다. MSAL.js 1.x에서 MSAL.js 2.x로 애플리케이션을 마이그레이션하여 웹 애플리케이션의 복원력을 실현합니다. 암시적 흐름은 새로 고침 토큰을 생성하지 않습니다. 브라우저에 Azure AD B2C와 활성 세션이 있는 경우 SPA는 숨겨진 iframe 토큰을 사용하여 권한 부여 엔드포인트에 대해 새 토큰 요청을 수행할 수 있습니다. SPA의 경우 사용자가 애플리케이션을 계속 사용할 수 있도록 하는 몇 가지 옵션이 있습니다.
    • 액세스 토큰의 유효 기간을 확장합니다.
    • API 게이트웨이를 인증 프록시로 사용하도록 애플리케이션을 빌드합니다. 이 구성에서 SPA는 인증 없이 로드되고 API 게이트웨이에 대한 API 호출이 수행됩니다. API 게이트웨이는 정책에 따라 권한 부여 코드 부여를 사용하여 로그인 프로세스를 통해 사용자를 보내고 사용자를 인증합니다. API 게이트웨이와 클라이언트 간의 인증 세션은 인증 쿠키를 사용하여 유지 관리됩니다. API 게이트웨이는 API 게이트웨이에서 가져온 토큰 또는 인증서, 클라이언트 자격 증명 또는 API 키와 같은 다른 직접 인증 방법을 사용하여 API를 서비스합니다.
    • 권장 옵션으로 전환합니다. PKCE(코드 교환용 증명 키) 및 CORS(원본 간 리소스 공유) 지원을 사용하여 SPA를 암시적 권한 부여 에서 권한 부여 코드 부여 흐름 으로 마이그레이션합니다.
    • 모바일 애플리케이션의 경우 새로 고침 및 액세스 토큰 수명을 확장합니다.
  • 백 엔드 또는 마이크로 서비스 애플리케이션: 백 엔드(디먼) 애플리케이션은 비대화형이며 사용자 컨텍스트에 없으므로 토큰 도난 가능성이 줄어듭니다. 보안과 수명 간의 균형을 맞추고 긴 토큰 수명을 설정하는 것이 좋습니다.

Single Sign-On

SSO(Single Sign-On)를 사용하면 사용자는 계정으로 한 번 로그인하고 플랫폼 또는 도메인 이름에 관계없이 웹, 모바일 또는 SPA(단일 페이지 애플리케이션)에 액세스할 수 있습니다. 사용자가 애플리케이션에 로그인하면 Azure AD B2C는 쿠키 기반 세션을 유지합니다.

후속 인증 요청 시 Azure AD B2C는 쿠키 기반 세션을 읽고 유효성을 검사하며 사용자에게 로그인하라는 메시지를 표시하지 않고 액세스 토큰을 발급합니다. SSO가 정책 또는 애플리케이션에서 제한된 범위로 구성된 경우 나중에 다른 정책 및 애플리케이션에 액세스하려면 새로운 인증이 필요합니다.

SSL 구성

여러 애플리케이션과 테넌트의 사용자 흐름이 동일한 사용자 세션을 공유할 수 있도록 테넌트 전체(기본값)로 SSO를 구성합니다. 테넌트 전체 구성은 최신 인증에 가장 강력한 복원력을 제공합니다.

안전한 배포 사례

가장 일반적인 서비스 중단은 코드 및 구성 변경입니다. CICD(지속적인 통합 및 지속적인 업데이트) 프로세스 및 도구를 채택하면 대규모로 배포할 수 있으며 테스트 및 배포 중에 인적 오류를 줄일 수 있습니다. 오류 감소, 효율성, 일관성을 위해 CICD를 채택합니다. Azure Pipelines가 CICD의 한 가지 예입니다.

봇으로부터 보호

OWASP Top-10에 설명된 DDoS(분산 서비스 거부) 공격, SQL 삽입, 교차 사이트 스크립팅, 원격 코드 실행 등과 같은 알려진 취약성으로부터 애플리케이션을 보호합니다. 일반적인 악용 및 취약성을 방어하기 위해 WAF(웹 애플리케이션 방화벽)를 배포합니다.

비밀

Azure AD B2C는 애플리케이션, API, 정책, 암호화에 비밀을 사용합니다. 비밀은 인증, 외부 상호 작용, 스토리지를 보호합니다. NIST(National Institute of Standards and Technology)는 합법적인 엔터티에서 사용하는 키 권한 부여의 시간 범위를 cryptoperiod로 나타냅니다. 필요한 cryptoperiods 길이 를 선택합니다. 만료를 설정하고 만료되기 전에 비밀을 회전합니다.

비밀 회전 구현

  • 지원되는 리소스에 관리 ID를 사용하여 Microsoft Entra 인증을 지원하는 모든 서비스를 인증할 수 있습니다. 관리 ID를 사용하는 경우 자격 증명 순환을 포함하여 리소스를 자동으로 관리할 수 있습니다.
  • Azure AD B2C에 구성된 키 및 인증서의 인벤토리를 가져옵니다. 이 목록에는 사용자 지정 정책, API, 서명 ID 토큰 및 SAML(Security Assertion Markup Language)에 사용되는 인증서에 사용되는 키가 포함될 수 있습니다.
  • CICD를 사용하여 예상되는 성수기로부터 2개월 이내에 만료되는 비밀을 회전합니다. 인증서에 연결된 프라이빗 키의 권장 암호 사용 기간은 최대 1년입니다.
  • API 액세스 자격 증명(예: 암호 및 인증서)을 모니터링하고 회전합니다.

REST API 테스트

복원력을 위해 REST API 테스트에는 HTTP 코드, 응답 페이로드, 헤더 및 성능 확인이 포함되어야 합니다. 행복한 경로 테스트만 사용하지 말고 API가 문제 시나리오를 정상적으로 처리하는지 확인합니다.

테스트 계획

테스트 계획에는 포괄적인 API 테스트가 포함된 것이 좋습니다. 프로모션 또는 휴일 트래픽으로 인한 급증의 경우 부하 테스트를 새로운 추정치로 수정합니다. 프로덕션이 아닌 개발자 환경에서 API 부하 테스트 및 CDN(Content Delivery Network)을 수행합니다.

다음 단계