다음을 통해 공유

제로 트러스트 원칙을 사용하여 애플리케이션 보안 강화

  • 아티클

개발된 애플리케이션 주변의 보안 네트워크 경계는 가정할 수 없습니다. 개발하는 거의 모든 앱은 기본적으로 네트워크 경계 외부에서 액세스됩니다. 애플리케이션은 개발 시 안전하거나 배포 후 안전하다는 보장이 없습니다. 애플리케이션 개발자는 애플리케이션의 보안을 최대화할 뿐만 아니라 애플리케이션이 손상될 경우 발생할 수 있는 손상을 최소화할 책임도 있습니다.

또한 애플리케이션이 제로 트러스트 보안 요구 사항을 충족할 것으로 예상하는 고객과 사용자의 진화하는 요구 사항을 지원할 책임이 있습니다. 제로 트러스트 모델의 원칙을 알아보고 사례를 채택합니다. 원칙을 학습하고 채택하면 보안 위반이 있을 경우 발생할 수 있는 손상을 최소화하고 보다 안전한 애플리케이션을 개발할 수 있습니다.

제로 트러스트 모델은 암시적 신뢰가 아닌 명시적 확인 문화를 규정합니다. 모델은 세 가지 주요 지침 원칙을 기반으로 합니다.

  • 명시적으로 확인
  • 최소 권한 액세스 사용
  • 위반 가정

제로 트러스트 모범 사례

모범 사례에 따라 Microsoft ID 플랫폼 및 해당 도구를 사용하여 제로 트러스트 지원 애플리케이션을 빌드합니다.

명시적으로 확인

Microsoft ID 플랫폼은 리소스에 액세스하는 사용자 또는 서비스의 ID를 확인하기 위한 인증 메커니즘을 제공합니다. 아래에 설명된 모범 사례를 적용하여 데이터 또는 리소스에 액세스해야 하는 엔터티를 명시적으로 확인합니다.

모범 사례 애플리케이션 보안의 이점
MSAL(Microsoft 인증 라이브러리)을 사용합니다. MSAL은 개발자를 위한 Microsoft 인증 라이브러리 세트입니다. MSAL을 사용하면 단 몇 줄의 코드만 사용하여 사용자 및 애플리케이션을 인증하고, 토큰을 획득하여 회사 리소스에 액세스할 수 있습니다. MSAL은 애플리케이션에서 사용자의 자격 증명을 직접 처리할 필요가 없도록 하는 최신 프로토콜(OpenID Connect 및 OAuth 2.0)을 사용합니다. 이렇게 자격 증명을 처리하면 ID 공급자가 보안 경계가 됨에 따라 사용자와 애플리케이션의 보안이 크게 향상됩니다. 또한 이러한 프로토콜은 ID 보안의 새로운 패러다임, 기회 및 과제를 해결하기 위해 지속적으로 발전하고 있습니다.
적절한 경우 CAE(지속적인 액세스 권한 평가) 및 조건부 액세스 인증 컨텍스트와 같은 향상된 보안 확장을 채택합니다. Microsoft Entra ID에서 가장 많이 사용되는 확장 중 일부에는 조건부 액세스, 조건부 액세스 인증 컨텍스트 및 CAE가 포함됩니다. CAE 및 조건부 액세스 인증 컨텍스트와 같은 향상된 보안 기능을 사용하는 애플리케이션은 클레임 챌린지를 처리하도록 코딩되어야 합니다. 개방형 프로토콜을 사용하면 클레임 챌린지 및 클레임 요청을 사용하여 추가 클라이언트 기능을 호출할 수 있습니다. 이 기능은 변칙이 있거나 사용자 인증 조건이 변경되는 경우 등에 Microsoft Entra ID와의 상호 작용을 계속하는 것일 수 있습니다. 이러한 확장은 인증을 위한 기본 코드 흐름을 방해하지 않고 애플리케이션으로 코딩할 수 있습니다.
인증 유형별로 올바른 인증 흐름을 사용합니다. 웹 애플리케이션의 경우 항상 기밀 클라이언트 흐름 사용을 시도해야 합니다. 모바일 애플리케이션의 경우 인증을 위해 broker 또는 시스템 브라우저를 사용해야 합니다. 비밀(기밀 클라이언트)을 보유할 수 있는 웹 애플리케이션의 흐름은 퍼블릭 클라이언트(예: 데스크톱 및 콘솔 애플리케이션)보다 더 안전한 것으로 간주됩니다. 시스템 웹 브라우저를 사용하여 모바일 애플리케이션을 인증하는 경우 보안 SSO(Single Sign-On) 환경을 통해 애플리케이션 보호 정책을 사용할 수 있습니다.

최소 권한 액세스 사용

개발자는 Microsoft ID 플랫폼을 사용하여 액세스 권한을 허용하기 전에 권한(범위)을 부여하고 호출자에게 적절한 권한을 부여했는지 확인합니다. 필요한 최소한의 액세스 권한을 부여할 수 있게 해주는 세분화된 권한을 사용하도록 설정하여 애플리케이션에서 최소 권한 액세스를 적용할 수 있습니다. 최소 권한 원칙을 준수하려면 다음 사례를 고려하세요.

  • 요청된 권한을 평가하여 작업을 완료하는 데 필요한 절대 최소 권한이 설정되어 있는지 확인합니다. 전체 API 표면에 액세스할 수 있는 "catch-all" 권한을 만들지 마세요.
  • API를 디자인할 때 최소 권한 액세스를 허용하는 세분화된 권한을 제공합니다. 범위 및 앱 역할을 사용하여 제어할 수 있는 섹션으로 기능 및 데이터 액세스를 나누는 것부터 시작합니다. 권한의 의미 체계를 변경하는 방식으로 기존 권한에 API를 추가하지 마세요.
  • 읽기 전용 권한을 제공합니다. Write 액세스에는 만들기, 업데이트 및 삭제 작업에 대한 권한이 포함됩니다. 클라이언트는 데이터 읽기에만 쓰기 권한을 요구해서는 안 됩니다.
  • 위임된 권한 및 애플리케이션 권한을 모두 제공합니다. 애플리케이션 권한을 건너뛰면 자동화, 마이크로 서비스 등과 같은 일반적인 시나리오를 달성하기 위해 클라이언트에 대한 하드 요구 사항이 만들어질 수 있습니다.
  • 중요한 데이터로 작업하는 경우 "표준" 및 "전체" 액세스 권한을 고려합니다. "표준" 액세스 권한(예: Resource.Read)을 사용하여 액세스할 수 없도록 중요한 속성을 제한합니다. 그런 다음, 중요한 정보를 포함하여 사용 가능한 모든 속성을 반환하는 "전체" 액세스 권한(예: Resource.ReadFull)을 구현합니다.

위반 가정

Microsoft ID 플랫폼 애플리케이션 등록 포털은 인증 및 관련 요구 사항에 플랫폼을 사용하려는 애플리케이션의 기본 진입점입니다. 애플리케이션을 등록하고 구성할 때 아래에 설명된 방법을 따라 보안 위반이 있는 경우 애플리케이션이 입을 수 있는 손상을 최소화합니다. 자세한 내용은 Microsoft Entra 애플리케이션 등록 보안 모범 사례를 참조하세요.

보안 위반을 방지하는 다음 조치를 고려합니다.

  • 애플리케이션의 리디렉션 URI를 올바르게 정의합니다. 여러 애플리케이션에 동일한 애플리케이션 등록을 사용하지 마세요.
  • 애플리케이션 등록에 사용된 리디렉션 URI의 소유권을 확인하고 도메인 인수를 방지합니다. 의도한 경우가 아니면 애플리케이션을 다중 테넌트로 만들지 마세요. |
  • 애플리케이션 및 서비스 주체 소유자가 테넌트에 등록된 애플리케이션에 대해 항상 정의되고 유지 관리되는지 확인합니다.

참고 항목