조건부 액세스 배포 계획

조건부 액세스 배포를 계획하는 것은 앱 및 리소스에 대한 조직의 액세스 전략을 구현하는 데 중요합니다. 조건부 액세스 정책은 뛰어난 구성 유연성을 제공합니다. 그러나 이러한 유연성은 바람직하지 않은 결과를 피하기 위해 신중하게 계획해야 함을 의미하기도 합니다.

Microsoft Entra 조건부 액세스 사용자, 디바이스 및 위치와 같은 신호를 결합하여 결정을 자동화하고 리소스에 대한 조직 액세스 정책을 적용합니다. 이러한 조건부 액세스 정책은 보안과 생산성의 균형을 유지하여 필요할 때 보안 제어를 적용하고 그렇지 않은 경우 사용자의’방해를 받지 않도록 하는 데 도움이 됩니다.

조건부 액세스는 Microsoft’의 제로 트러스트 보안 정책 엔진 기반입니다.

Microsoft는 Microsoft Entra ID P1 또는 P2가 없는 테넌트에서 기본 보안 수준을 사용하도록 설정하는 보안 기본값을 제공합니다. 조건부 액세스를 사용하면 보안 기본값과 동일한 보호를 제공하지만 세분성으로 정책을 만들 수 있습니다. 조건부 액세스 및 보안 기본값은 조건부 액세스 정책을 만들면 보안 기본값을 사용할 수 없으므로 결합되지 않습니다.

필수 조건

• Microsoft Entra ID P1, P2 또는 평가판 라이선스가 사용하도록 설정된 작동 중인 Microsoft Entra 테넌트입니다. 필요한 경우, 체험 계정을 만드세요.
  • 조건부 액세스 정책에 Microsoft Entra ID 보호 위험을 포함하려면 Microsoft Entra ID P2가 필요합니다.
• 조건부 액세스와 상호 작용하는 관리자는 수행하는 작업에 따라 다음 역할 할당 중 하나가 있어야 합니다. 최소 권한의 제로 트러스트 원칙을 따르려면 PIM(Privileged Identity Management)을 사용하여 Just-In-Time에 권한 있는 역할 할당을 활성화하는 것이 좋습니다.
  • 조건부 액세스 정책 및 구성 읽기
    • 보안 읽기 권한자
  • 조건부 액세스 정책 만들기 또는 수정
    • 조건부 액세스 관리자
• 실제 사용자에게 배포하기 전에 정책이 예상대로 작동하는지 확인할 수 있는 테스트 사용자(관리자 아님)입니다. 사용자를 만들어야 하는 경우 빠른 시작: Microsoft Entra ID에 새 사용자 추가의 정보를 사용할 수 있습니다.
• 테스트 사용자가 구성원인 그룹입니다. 그룹을 만들어야 하는 경우 Microsoft Entra ID에서 그룹 만들기 및 멤버 추가를 참조하세요.

변경 내용 전달

커뮤니케이션은 새로운 기능의 성공에 매우 중요합니다. 사용자의 경험이 어떻게 변화하고 언제 변할 것인지, 문제가 발생할 경우 지원을 받는 방법에 대해 사용자와 적극적으로 소통해야 합니다.

조건부 액세스 정책 구성 요소

조건부 액세스 정책은 리소스에 액세스할 수 있는 사람, 액세스할 수 있는 리소스 및 조건에 대한 질문에 답합니다. 정책은 액세스 권한을 부여하거나, 세션 제어를 사용하여 액세스를 제한하거나, 액세스를 차단하도록 설계할 수 있습니다. 다음과 같은 if-then 문을 정의하여 조건부 액세스 정책을 빌드합니다.

할당이 충족되는 경우	액세스 제어 적용
Payroll 애플리케이션에 액세스하는 Finance의 사용자인 경우	다단계 인증 및 호환 디바이스 필요
Payroll 애플리케이션에 액세스하는 재무 멤버가 아닌 경우	액세스 차단
사용자 위험이 높은 경우	다단계 인증 및 보안 암호 변경 요구

사용자 제외

조건부 액세스 정책은 강력한 도구이므로 정책에서 다음 계정을 제외하는 것이 좋습니다.

• 정책 잘못된 구성으로 인한 잠금을 방지하기 위한 비상 액세스 또는 비상 계정 드문 시나리오에서 모든 관리자가 잠기면 응급 액세스 관리 계정을 사용하여 로그인하고 액세스를 복구하는 단계를 수행할 수 있습니다.
  • 자세한 내용은 Microsoft Entra ID에서 긴급 액세스 계정 관리 문서를 참조하세요.
• 서비스 계정 및 서비스 주체(예: Microsoft Entra Connect 동기화 계정). 서비스 계정은 특정 사용자에게 연결되지 않은 비대화형 계정입니다. 일반적으로 애플리케이션에 대한 프로그래매틱 액세스를 허용하는 백 엔드 서비스에서 사용하지만 관리 목적으로 시스템에 로그인할 때도 사용합니다. 서비스 주체가 수행한 호출은 사용자로 범위가 지정된 조건부 액세스 정책에서 차단하지 않습니다. 워크로드 ID에 조건부 액세스를 사용하여 서비스 주체를 대상으로 하는 정책을 정의합니다.
  • 조직에서 스크립트 또는 코드에 이러한 계정을 사용 중인 경우 이를 관리 ID로 바꾸는 것이 좋습니다.

올바른 질문하기

다음은 할당 및 액세스 제어에 대한 몇 가지 일반적인 질문입니다. 각 정책을 빌드하기 전에 해당 질문에 대한 대답을 문서화합니다.

사용자 또는 워크로드 ID

• 정책에서 포함되거나 제외되는 사용자, 그룹, 디렉터리 역할 또는 워크로드 ID는 무엇인가요?
• 정책에서 제외해야 하는 응급 액세스 계정 또는 그룹은 무엇인가요?

클라우드 앱 또는 작업

이 정책은 애플리케이션, 사용자 동작 또는 인증 컨텍스트에 적용될까요? 답이 ‘예’인 경우:

• 정책이 적용되는 애플리케이션 또는 서비스는 무엇인가요?
• 이 정책의 적용을 받는 사용자 작업은 무엇인가요?
• 이 정책이 적용되는 인증 컨텍스트는 무엇인가요?

애플리케이션 필터링

애플리케이션에 필터를 사용하여 애플리케이션을 개별적으로 지정하는 대신 애플리케이션을 포함하거나 제외하는 조직에 도움이 됩니다.

• 여러 애플리케이션의 크기를 쉽게 조정하고 대상으로 지정합니다.
• 유사한 정책 요구 사항을 사용하여 애플리케이션을 쉽게 관리합니다.
• 개별 정책 수를 줄입니다.
• 정책을 편집하는 동안 오류 줄이기: 정책에서 애플리케이션을 수동으로 추가/제거할 필요가 없습니다. 특성을 관리하기만 하면 좋습니다.
• 정책 크기 제약 조건을 극복합니다.

조건

• 정책에 포함되거나 정책에서 제외되는 디바이스 플랫폼은 무엇입니까?
• 조직의 알려진 네트워크 위치는 무엇인가요?
  • 정책에 포함되거나 정책에서 제외되는 위치는 무엇인가요?
• 정책에 포함되거나 정책에서 제외되는 클라이언트 앱 유형은 무엇인가요?
• 특정 디바이스 특성을 대상으로 해야 하나요?
• Microsoft Entra ID Protection을 사용하는 경우 로그인 또는 사용자 위험을 통합하시겠습니까?

제어 차단 또는 부여

다음 중 하나 이상을 요구하여 리소스에 대한 액세스 권한을 부여하시겠습니까?

• Multi-Factor Authentication
• 규격으로 표시된 디바이스
• Microsoft Entra 하이브리드 조인 디바이스 사용
• 승인된 클라이언트 앱 사용
• 앱 보호 정책 적용됨
• 암호 변경
• 사용 약관 수락됨

액세스 차단은 적절한 지식을 사용하여 적용해야 하는 강력한 제어 기능입니다. 차단 문이 있는 정책에는 의도하지 않은 부작용이 발생할 수 있습니다. 제어를 대규모로 사용하도록 설정하기 전에 적절한 테스트 및 유효성 검사가 중요합니다. 관리자는 변경할 때 조건부 액세스 보고서 전용 모드 및 조건부 액세스의 What If 도구와 같은 도구를 사용해야 합니다.

세션 컨트롤

클라우드 앱에서 다음 액세스 제어를 적용하시겠습니까?

• 앱에서 적용된 제한 사항 사용
• 조건부 액세스 앱 제어 사용
• 로그인 빈도 적용
• 영구 브라우저 세션 사용
• 지속적인 액세스 권한 평가 사용자 지정

정책 결합

정책을 만들고 할당할 때 액세스 토큰의 작동 방식을 고려해야 합니다. 액세스 토큰은 요청하는 사용자에게 권한이 부여되고 인증되었는지 여부에 따라 액세스 권한을 부여하거나 거부합니다. 요청자가 자신의 클레임을 입증할 수 있으면 보호된 리소스나 기능에 액세스할 수 있습니다.

조건부 액세스 정책 조건에서 액세스 제어를 트리거하지 않으면 액세스 토큰이 기본적으로 발급됩니다.

이 정책은 앱이 액세스를 차단하는 자체 기능을 갖는 것을 막지 않습니다.

예를 들어, 다음과 같은 간소화된 정책 예를 고려합니다.

사용자: FINANCE GROUP
액세스: PAYROLL 앱
액세스 제어: 다단계 인증

• 사용자 A는 FINANCE GROUP에 속해 있으며 PAYROLL 앱에 액세스하려면 다단계 인증을 수행해야 합니다.
• 사용자 B는 FINANCE GROUP에 속하지 않고 액세스 토큰을 발급받았으며 다단계 인증을 수행하지 않고도 PAYROLL 앱에 액세스할 수 있습니다.

재무 그룹 외부의 사용자가 급여 앱에 액세스할 수 없도록 하기 위해 다음과 같은 간소화된 정책과 같이 다른 모든 사용자를 차단하는 별도의 정책을 만들 수 있습니다.

사용자: 모든 사용자 포함/FINANCE GROUP 제외
액세스: PAYROLL 앱
액세스 제어: 액세스 차단

이제 사용자 B가 PAYROLL 앱에 액세스하려고 하면 차단됩니다.

권장 사항

조건부 액세스 사용 및 다른 고객 지원에 대한 학습 내용을 고려하여 다음은 학습 내용을 기반으로 한 몇 가지 권장 사항입니다.

모든 앱에 조건부 액세스 정책 적용

모든 앱에 하나 이상의 조건부 액세스 정책이 적용되어 있는지 확인합니다. 보안 관점에서 모든 리소스(이전의 '모든 클라우드 앱')를 포함하는 정책을 만든 다음 정책을 적용하지 않으려는 애플리케이션을 제외하는 것이 좋습니다. 이렇게 하면 새 애플리케이션을 온보딩할 때마다 조건부 액세스 정책을 업데이트할 필요가 없습니다.

팁

단일 정책에서 차단 및 모든 앱을 사용하는 경우 매우 주의해야 합니다. 이로 인해 관리자가 로그인을 하지 못할 수 있으며, Microsoft Graph와 같은 중요한 엔드포인트에 대한 예외는 구성할 수 없습니다.

조건부 액세스 정책 수 최소화

각 앱에 대한 정책을 만드는 것은 비효율적이며 관리가 어려워집니다. 조건부 액세스는 테넌트당 195개 정책으로 제한됩니다. 이 195 정책 제한에는 보고서 전용 모드, 켜기 또는 해제를 포함한 모든 상태의 조건부 액세스 정책이 포함됩니다.

앱을 분석하여 동일한 사용자에 대한 동일한 리소스 요구 사항이 있는 애플리케이션으로 그룹화하는 것이 좋습니다. 예를 들어 모든 Microsoft 365 앱 또는 모든 HR 앱에 동일한 사용자에 대한 동일한 요구 사항이 있는 경우 단일 정책을 만들고 해당 정책이 적용되는 모든 앱을 포함합니다.

조건부 액세스 정책은 JSON 파일에 포함되며 해당 파일은 단일 정책이 확장될 것으로 예상하지 않는 크기 제한에 바인딩됩니다. 정책에서 긴 GUID 목록을 사용하는 경우 이 제한에 도달할 수 있습니다. 이러한 제한이 발생하는 경우 다음과 같은 대안을 사용하는 것이 좋습니다.

• 그룹 또는 역할을 사용하여 각 사용자를 개별적으로 나열하는 대신 사용자를 포함하거나 제외합니다.
• 개별적으로 지정하는 대신 애플리케이션에 필터를 사용하여 애플리케이션을 포함하거나 제외합니다.

보고서 전용 모드 구성

기본적으로 템플릿에서 만들어진 각 정책은 보고 전용 모드로 만들어집니다. 조직에서 각 정책을 실행하기 전에 의도한 결과를 보장하기 위해 사용량을 테스트하고 모니터링하는 것이 좋습니다.

보고 전용 모드에서 정책을 사용하도록 설정합니다. 보고 전용 모드에서 정책을 저장하면 로그인 로그에서 실시간 로그인에 미치는 영향을 확인할 수 있습니다. 로그인 로그에서 이벤트를 선택하고, 보고 전용 탭으로 이동하여 각 보고 전용 정책의 결과를 확인합니다.

Insights and Reporting 통합 문서에서 조건부 액세스 정책의 종합적인 영향을 볼 수 있습니다. 통합 문서에 액세스하려면 Azure Monitor 구독이 필요하며 로그인 로그를 log analytics 작업 영역 스트리밍해야 합니다.

중단 계획

예기치 않은 중단 시 잠금 위험을 줄이기 위해 조직에 복원력 전략을 계획합니다.

보호된 작업 사용

보호된 작업을 사용하도록 설정하면 조건부 액세스 정책을 만들거나 수정하거나 삭제하려는 시도에 다른 보안 계층이 적용됩니다. 조직은 정책을 수정하기 전에 새로운 다단계 인증 또는 기타 권한 부여 제어를 요구할 수 있습니다.

정책에 대한 이름 지정 표준 설정

이름 지정 표준은 정책을 찾고 Azure 관리 포털에서 열지 않고도 해당 용도를 파악하는 데 도움이 됩니다. 표시할 정책의 이름을 지정하는 것이 좋습니다.

• 시퀀스 번호
• 적용되는 클라우드 앱
• 응답
• 정책이 적용되는 대상
• 정책이 적용되는 시기

예: 외부 네트워크에서 Dynamics CRP 앱에 액세스하는 마케팅 사용자에게 MFA를 요구하는 정책은 다음과 같을 수 있습니다.

설명이 포함된 이름을 사용하면 조건부 액세스 구현에 대한 개요를 유지할 수 있습니다. 시퀀스 번호는 대화에서 정책을 참조해야 하는 경우에 유용합니다. 예를 들어 관리자에게 전화로 연락하는 경우 문제를 해결하기 위해 CA01 정책을 열도록 요청할 수 있습니다.

응급 액세스 제어의 이름 지정 표준

활성 정책 외에도 중단 또는 응급 시나리오에서 복원력 있는 보조 액세스 제어로 작동하지만 사용하지 않도록 설정되는 정책을 구현합니다. 대응 정책에 대한 이름 지정 표준에 포함되어야 하는 항목은 다음과 같습니다.

• 다른 정책 중에서 이름을 구분할 수 있도록 시작 부분에 ENABLE IN EMERGENCY(응급 시 사용) 사용
• 적용해야 하는 중단의 이름
• 관리자가 사용하도록 설정해야 하는 순서 정책을 파악하는 데 도움이 되는 순서 지정 시퀀스 번호

예: MFA 중단이 발생하는 경우 사용하도록 설정하는 네 가지 정책 중 첫 번째 정책임을 나타내는 이름은 다음과 같습니다.

• EM01 - 응급 상황에서 사용: MFA 중단[1/4] - VIP 사용자의 경우 Exchange SharePoint: Microsoft Entra 하이브리드 조인이 필요합니다.

로그인을 기대하지 않는 국가/지역 차단

Microsoft Entra ID를 사용하면 이름이 지정된 위치를 만들 수 있습니다. 허용되는 국가/지역 목록을 만든 다음 이러한 "허용된 국가/지역"을 제외하여 네트워크 차단 정책을 만듭니다. 이 옵션을 사용하면 더 작은 지리적 위치에 기반을 둔 고객의 오버헤드가 줄어듭니다. 이 정책에서 긴급 액세스 계정을 제외해야 합니다.

조건부 액세스 정책 배포

준비가 되면 조건부 액세스 정책을 단계적으로 배포합니다.

조건부 액세스 정책 빌드

유리한 출발을 위해 조건부 액세스 정책 템플릿 및 Microsoft 365 조직을 위한 일반 보안 정책을 참조하세요. 이러한 템플릿은 Microsoft 권장 사항을 배포하는 편리한 방법입니다. 응급 액세스 계정을 제외해야 합니다.

정책 영향 평가

다음 도구를 사용하여 변경 전후에 정책의 효과를 평가하는 것이 좋습니다. 시뮬레이션된 실행은 조건부 액세스 정책이 미치는 영향에 대한 좋은 아이디어를 제공하며 적절하게 구성된 개발 환경에서 실제 테스트 실행을 바꾸지 않습니다.

• 보고 전용 모드 및 조건부 액세스 인사이트 및 보고 통합 문서.
• What If 도구

정책 테스트

정책의 제외 조건을 테스트해야 합니다. 예를 들어 MFA가 필요한 정책에서 사용자 또는 그룹을 제외할 수 있습니다. 다른 정책을 조합하면 제외된 사용자에게 MFA를 요구할 수도 있으므로 해당 사용자에게 MFA를 요구하는 메시지가 표시되는지 테스트합니다.

테스트 계획의 각 테스트는 테스트 사용자를 통해 수행합니다. 테스트 계획은 예상 결과와 실제 결과 간에 비교하는 것이 중요합니다. 다음 표에는 몇 가지 예제 테스트 사례가 요약되어 있습니다. 조건부 액세스 정책이 구성된 방식에 따라 시나리오와 예상 결과를 조정합니다.

정책	시나리오	예상 결과
위험한 로그인	사용자가 승인되지 않은 브라우저를 사용하여 앱에 로그인	사용자가 로그인하지 않았을 확률에 따라 위험 점수를 계산합니다. 사용자가 MFA를 사용하여 자체 수정해야 함
디바이스 관리	권한 있는 사용자가 권한 있는 디바이스에서 로그인하려고 시도함	액세스 권한 부여됨
디바이스 관리	권한 있는 사용자가 권한 없는 디바이스에서 로그인하려고 시도함	액세스 차단됨
위험한 사용자에 대한 암호 변경	권한 있는 사용자가 손상된 자격 증명을 사용하여 로그인하려고 함(높은 위험 로그인)	사용자에게 암호를 변경하라는 메시지가 표시되거나 정책에 따라 액세스가 차단됨

프로덕션에 배포

보고 전용 모드를 사용하여 영향을 확인한 후 관리자는 정책 사용 토글을 보고 전용에서 켜기로 전환할 수 있습니다.

정책 롤백

새로 구현된 정책을 롤백해야 하는 경우 다음 옵션 중 하나 이상을 사용합니다.

• 정책을 사용하지 않도록 설정합니다. 정책을 사용하지 않도록 설정하면 사용자가 로그인을 시도할 때 해당 정책이 적용되지 않습니다. 이 정책을 사용하려면 언제든지 다시 돌아와서 해당 정책을 사용하도록 설정할 수 있습니다.

• 정책에서 사용자 또는 그룹을 제외합니다. 사용자가 앱에 액세스할 수 없는 경우 정책에서 사용자를 제외하도록 선택할 수 있습니다.

  주의

  제외는 드물게 사용되어야 하며 사용자를 신뢰할 수 있는 상황에서만 사용해야 합니다. 가능한 한 빨리 사용자를 정책 또는 그룹에 다시 추가해야 합니다.

• 정책이 사용 중지되어 더 이상 필요하지 않은 경우 삭제합니다.

조건부 액세스 정책 문제 해결

사용자에게 조건부 액세스 정책에 문제가 있는 경우 문제 해결을 용이하게 하기 위해 다음 정보를 수집합니다.

• 사용자 계정 이름
• 사용자 표시 이름
• 운영 체제 이름
• 타임스탬프(근삿값도 허용됨)
• 대상 애플리케이션
• 클라이언트 애플리케이션 유형(브라우저 및 클라이언트)
• 상관 관계 ID(이 ID는 로그인에 고유함)

사용자가 자세한 정보 링크를 포함한 메시지를 받은 경우 이 정보의 대부분을 수집할 수 있습니다.

정보를 수집하면 다음 리소스를 참조하세요.

• 조건부 액세스 로그인 문제 – 오류 메시지 및 Microsoft Entra 로그인 로그를 사용하여 조건부 액세스와 관련된 예기치 않은 로그인 결과를 이해합니다.
• What-If 도구 사용 - 특정 상황에서 정책이 사용자에게 적용되거나 적용되지 않은 이유 또는 정책이 알려진 상태에서 적용되는지 여부를 파악합니다.

관련 콘텐츠

• 다단계 인증에 대해 자세히 알아보기
• Microsoft Entra ID Protection에 대해 자세히 알아보기
• Microsoft Graph API를 사용하여 조건부 액세스 정책 관리