환경의 애플리케이션 액세스를 제어하기 위한 조직 정책 정의

Microsoft Entra ID를 사용하여 액세스를 제어하려는 애플리케이션을 하나 이상 확인한 후에는 액세스 권한이 필요한 사용자 및 시스템에서 제공해야 하는 다른 제약 조건을 결정하기 위한 조직의 정책을 작성합니다.

범위 내에서 애플리케이션 및 해당 역할 식별

규정 준수 요구 사항 또는 위험 관리 계획이 있는 조직에는 중요한 애플리케이션이나 중요 비즈니스용 애플리케이션이 있습니다. 이 애플리케이션이 환경의 기존 애플리케이션인 경우 이 애플리케이션에 대한 '액세스 권한이 필요한' 사용자에 대한 액세스 정책을 이미 문서화했을 수 있습니다. 기존 애플리케이션이 아닌 경우 규정 준수 및 위험 관리 팀과 같은 다양한 관련자와 협의하여 액세스 권한 결정을 자동화하는 데 사용되는 정책이 시나리오에 적합한지 확인해야 할 수 있습니다.

  1. 각 애플리케이션에서 제공하는 역할 및 권한을 수집합니다. "사용자" 역할만 있는 애플리케이션처럼 단일 역할만 있는 애플리케이션도 있을 수 있습니다. 좀 더 복잡한 애플리케이션은 Microsoft Entra ID를 통해 관리해야 하는 여러 역할을 노출할 수 있습니다. 이러한 애플리케이션 역할은 일반적으로 해당 역할을 가진 사용자가 앱 내에서 갖게 되는 액세스 권한에 대한 광범위한 제약 조건을 만듭니다. 예를 들어 관리자 가상 사용자가 있는 애플리케이션에는 "사용자" 및 "관리자"라는 두 가지 역할이 있을 수 있습니다. 다른 애플리케이션은 프로비저닝의 Microsoft Entra ID 애플리케이션 또는 페더레이션 SSO 프로토콜을 사용하여 발급된 클레임에 제공하거나 보안 그룹 멤버 자격으로 AD에 작성할 수 있는 그룹 멤버 자격 또는 클레임을 세밀한 역할 검사에 사용할 수도 있습니다. 마지막으로, Microsoft Entra ID에 표시되지 않는 애플리케이션별 역할이 있을 수 있습니다. 애플리케이션이 Microsoft Entra ID에서 관리자를 정의하는 것을 허용하지 않고 대신 자체 권한 부여 규칙에 의존하여 관리자를 식별할 수 있습니다. SAP Cloud Identity Services에는 할당할 수 있는 사용자 역할이 하나뿐입니다.

    참고 항목

    프로비저닝을 지원하는 Microsoft Entra 애플리케이션 갤러리의 애플리케이션을 사용하는 경우 Microsoft Entra ID는 프로비저닝이 구성되면 애플리케이션에서 정의된 역할을 가져오고 애플리케이션 매니페스트를 애플리케이션의 역할로 자동 업데이트할 수 있습니다.

  2. Microsoft Entra ID에서 관리할 멤버 자격이 있는 역할과 그룹을 선택합니다. 규정 준수 및 위험 관리 요구 사항에 따라 조직은 종종 권한 있는 액세스 권한 또는 중요한 정보에 대한 액세스 권한을 부여하는 해당 애플리케이션 역할 또는 그룹의 우선 순위를 지정합니다.

애플리케이션에 액세스하기 위한 필수 조건 및 기타 제약 조건으로 조직의 정책 정의

이 섹션에서는 애플리케이션에 대한 액세스 권한을 결정하는 데 사용할 조직 정책을 작성합니다. 예를 들어 정책을 스프레드시트에 테이블로 기록할 수 있습니다.

앱 역할 액세스 필수 조건 승인자 기본 액세스 기간 의무 분리 제약 조건 조건부 액세스 정책
서부 영업 영업 팀 구성원 사용자의 관리자 연간 검토 동부 영업 액세스 권한을 가질 수 없음 액세스하려면 MFA(다단계 인증) 및 등록된 디바이스 필요
서부 영업 영업 팀 외부의 모든 직원 영업 부서장 90일 해당 없음 액세스하려면 MFA 및 등록된 디바이스 필요
서부 영업 직원이 아닌 영업 담당자 영업 부서장 30일 해당 없음 액세스하려면 MFA 필요
동부 영업 영업 팀 구성원 사용자의 관리자 연간 검토 서부 영업 액세스 권한을 가질 수 없음 액세스하려면 MFA 및 등록된 디바이스 필요
동부 영업 영업 팀 외부의 모든 직원 영업 부서장 90일 해당 없음 액세스하려면 MFA 및 등록된 디바이스 필요
동부 영업 직원이 아닌 영업 담당자 영업 부서장 30일 해당 없음 액세스하려면 MFA 필요

조직 역할 정의가 이미 있는 경우 자세한 내용은 조직 역할을 마이그레이션하는 방법을 참조하세요.

  1. 필수 요구 사항, 즉, 사용자가 애플리케이션 액세스 권한을 얻으려면 충족해야 하는 표준이 있는지 확인합니다. 예를 들어 정상적인 상황에서는 정규직 직원 또는 특정 부서나 비용 센터의 직원만 특정 부서의 애플리케이션에 액세스할 수 있어야 합니다. 또한 하나 이상의 추가 승인자를 갖도록 액세스 권한을 요청하는 다른 부서의 사용자에 대한 권한 관리 정책이 필요할 수 있습니다. 여러 승인 단계가 있으면 사용자가 액세스 권한을 얻는 전체 프로세스가 느려질 수 있지만, 이러한 추가 단계가 있으면 적절한 액세스 요청이 보장되고 의사 결정의 책임이 명확해집니다. 예를 들어 직원의 액세스 요청은 첫 번째로 요청하는 사용자의 관리자가 승인하고 두 번째로 애플리케이션에 보관된 데이터를 담당하는 리소스 소유자 중 한 명이 승인하는 두 단계로 구성될 수 있습니다.

  2. 액세스가 승인된 사용자에게 액세스 권한이 필요한 기간과 액세스 권한이 사라져야 하는 시기를 결정합니다. 많은 애플리케이션의 경우 사용자가 조직을 떠날 때까지 액세스 권한을 무기한 유지할 수 있습니다. 경우에 따라 프로젝트가 종료되면 액세스 권한이 자동으로 제거되도록 액세스 권한이 특정 프로젝트 또는 마일스톤에 연결될 수도 있습니다. 또는 소수의 사용자만 정책을 통해 애플리케이션을 사용하는 경우 해당 정책을 통해 모든 사용자의 액세스 권한을 분기마다 또는 매년 검토하도록 구성하여 정기적으로 감독할 수 있습니다.

  3. 조직에서 이미 조직 역할 모델을 사용하여 액세스를 관리하고 있는 경우 해당 조직 역할 모델을 Microsoft Entra ID로 가져올 계획을 세우세요. 사용자의 직책이나 부서와 같은 속성에 따라 액세스 권한을 할당하는 조직 역할을 정의할 수 있습니다. 이러한 프로세스는 미리 결정된 프로젝트 종료 날짜가 없더라도 액세스 권한이 더 이상 필요 없으면 사용자가 액세스 권한을 잃게 할 수 있습니다.

  4. 의무 분리 제약 조건이 있는지 문의합니다. 예를 들어 서부 영업동부 영업이라는 두 가지 앱 역할을 포함하는 애플리케이션이 있고 사용자가 한 번에 하나의 영업권역에만 속할 수 있도록 지정할 수 있습니다. 사용자에게 하나의 역할이 있는 경우 두 번째 역할을 요청할 수 없도록 애플리케이션과 호환되지 않는 앱 역할 쌍의 목록을 포함합니다.

  5. 애플리케이션에 액세스하기 위한 적절한 조건부 액세스 정책을 선택하세요. 애플리케이션을 분석하여 동일한 사용자에 대한 동일한 리소스 요구 사항이 있는 애플리케이션으로 그룹화하는 것이 좋습니다. ID 거버넌스를 위해 Microsoft Entra ID 거버넌스와 통합하는 첫 번째 페더레이션된 SSO 애플리케이션인 경우 MFA(다단계 인증) 또는 위치 기반 액세스 요구 사항과 같은 제약 조건을 표현하는 새로운 조건부 액세스 정책을 만들어야 할 수 있습니다. 사용자가 사용 약관에 동의하도록 구성할 수 있습니다. 조건부 액세스 정책을 정의하는 방법에 관한 자세한 고려 사항은 조건부 액세스 배포 계획을 참조하세요.

  6. 조건에 대한 예외를 처리하는 방법을 결정합니다. 예를 들어 애플리케이션은 일반적으로 지정된 직원만 사용할 수 있지만, 감사자 또는 공급업체가 특정 프로젝트에 대한 임시 액세스 권한이 필요할 수 있습니다. 또는 조직의 사무실이 하나도 없어서 일반적으로 액세스가 차단되는 위치로 출장을 간 직원이 해당 위치에서 액세스해야 할 때가 있습니다. 이러한 상황에서는 다른 단계, 다른 시간 제한 또는 다른 승인자가 있을 수 있는 승인에 대한 권한 관리 정책을 사용하도록 선택할 수도 있습니다. Microsoft Entra 테넌트에서 게스트 사용자로 로그인한 공급업체에는 관리자가 없을 수 있으므로 조직의 스폰서, 리소스 소유자 또는 보안 담당자가 이들의 액세스 요청을 승인할 수 있습니다.

액세스 권한이 필요한 사용자에 대한 조직 정책을 관련자가 검토하면 애플리케이션을 Microsoft Entra ID와 통합할 수 있습니다. 이렇게 하면 이후 단계에서 Microsoft Entra ID 거버넌스의 액세스 권한에 대해 조직에서 승인한 정책을 배포할 준비가 됩니다.

다음 단계