다음을 통해 공유

Microsoft Entra ID와 애플리케이션 통합 및 검토된 액세스 기준 설정

  • 아티클

애플리케이션에 대한 액세스 권한이 필요한 사용자에 대한 정책을 설정한 후, 애플리케이션을 Microsoft Entra ID에 연결하고 나서 해당 정책을 액세스를 관리하기 위해 배포할 수 있습니다.

Microsoft Entra ID 거버넌스는 SAP R/3, SAP S/4HANA 및 OpenID Connect, SAML, SCIM, SQL, LDAP, SOAP 및 REST와 같은 표준을 사용하는 애플리케이션과 통합할 수 있습니다. 이러한 표준을 통해 조직에서 개발한 애플리케이션을 포함하여 널리 사용되는 많은 SaaS 애플리케이션 및 온-프레미스 애플리케이션에서 Microsoft Entra ID를 사용할 수 있습니다. 이 배포 계획은 애플리케이션을 Microsoft Entra ID에 연결하고 해당 애플리케이션에 사용할 ID 거버넌스 기능을 사용하도록 설정하는 방법을 설명합니다.

애플리케이션에 Microsoft Entra ID 거버넌스를 사용하려면 먼저 애플리케이션을 Microsoft Entra ID와 통합하고 디렉터리에 표시해야 합니다. Microsoft Entra ID와 통합되는 애플리케이션은 다음 두 가지 요구 사항 중 하나를 충족해야 임을 의미합니다.

  • 애플리케이션은 페더레이션된 SSO에 대해 Microsoft Entra ID를 사용하고 Microsoft Entra ID는 인증 토큰 발급을 제어합니다. Microsoft Entra ID가 애플리케이션의 유일한 ID 공급자인 경우 Microsoft Entra ID에서 애플리케이션의 역할 중 하나에 할당된 사용자만 애플리케이션에 로그인할 수 있습니다. 애플리케이션 역할 할당이 손실된 사용자는 더 이상 애플리케이션에 로그인할 새 토큰을 가져올 수 없습니다.
  • 애플리케이션은 Microsoft Entra ID로 애플리케이션에 제공되는 사용자 또는 그룹 목록을 사용합니다. 이 처리는 SCIM과 같은 프로비저닝 프로토콜, Microsoft Graph를 통해 Microsoft Entra ID를 쿼리하는 애플리케이션 또는 AD Kerberos를 사용하여 사용자의 그룹 멤버 자격을 얻는 애플리케이션을 통해 수행할 수 있습니다.

애플리케이션에 대해 이러한 조건이 충족되지 않는 경우(예: 애플리케이션이 Microsoft Entra ID를 사용하지 않는 경우) ID 거버넌스를 계속 사용할 수 있습니다. 그러나 조건을 충족하지 않고 ID 거버넌스를 사용하는 데 몇 가지 제한 사항이 있을 수 있습니다. 예를 들어 Microsoft Entra ID에 없거나 Microsoft Entra ID의 애플리케이션 역할에 할당되지 않은 사용자는 애플리케이션 역할에 할당할 때까지 애플리케이션의 액세스 검토에 포함되지 않습니다. 자세한 내용은 사용자의 애플리케이션 접근에 대한 액세스 검토 준비를 참조하세요.

Microsoft Entra ID와 애플리케이션을 통합하여 권한 있는 사용자만 애플리케이션에 액세스할 수 있도록 합니다.

애플리케이션 프로세스의 통합은 페더레이션된 SSO(Single Sign-On) 프로토콜 연결을 사용하여 사용자 인증을 위해 Microsoft Entra ID를 사용하도록 해당 애플리케이션을 구성한 다음 프로비저닝을 추가할 때 시작됩니다. SSO에 가장 일반적으로 사용되는 프로토콜은 SAML 및 OpenID Connect . 애플리케이션 인증을 검색하고 Microsoft Entra ID 마이그레이션하는도구 및 프로세스에 대해 자세히 확인할 수 있습니다.

다음으로, 애플리케이션이 프로비저닝 프로토콜을 구현하는 경우 Microsoft Entra ID를 구성하여 사용자를 애플리케이션에 프로비전해야 합니다. 그러면 사용자에게 액세스 권한이 부여되었거나 사용자의 액세스 권한이 제거되었을 때 Microsoft Entra ID가 애플리케이션에 신호를 보낼 수 있습니다. 이러한 프로비저닝 신호를 통해 애플리케이션은 퇴사한 직원이 만든 콘텐츠를 그들의 관리자에게 다시 할당하는 등의 자동 수정을 수행할 수 있습니다.

  1. 애플리케이션이 엔터프라이즈 애플리케이션 목록에 있는지 또는 앱 등록 목록에 있는지 확인합니다. 애플리케이션이 테넌트에 이미 있는 경우 이 섹션의 5단계로 건너뜁니다.

  2. 애플리케이션이 테넌트에 아직 등록되지 않은 SaaS 애플리케이션인 경우 페더레이션된 SSO에 통합할 수 있는 애플리케이션 갤러리 사용 가능한 애플리케이션을 확인합니다. 갤러리에 있는 경우 자습서를 사용하여 애플리케이션을 Microsoft Entra ID와 통합합니다.

    1. 자습서 따라 Microsoft Entra ID를 사용하여 페더레이션된 SSO에 대한 애플리케이션을 구성합니다.
    2. 애플리케이션이 프로비저닝을 지원하는 경우 프로비전할 애플리케이션을 구성합니다.
    3. 완료되면 이 문서의 다음 섹션으로 건너뜁니다. SaaS 애플리케이션이 갤러리에 없는 경우 SaaS 공급업체에등록하도록 요청합니다.

  3. 프라이빗 또는 사용자 지정 애플리케이션인 경우 애플리케이션의 위치 및 기능에 따라 가장 적합한 Single Sign-On 통합을 선택할 수도 있습니다.

    • 이 애플리케이션이 SAP BTP(비즈니스 기술 플랫폼)에 있는 경우 SAP Cloud Identity Services와 Microsoft Entra 통합을 구성합니다. 자세한 내용은 SAP BTP Microsoft Entra SSO 통합 및 SAP BTP 대한 액세스 관리 참조하세요.

    • 이 애플리케이션이 퍼블릭 클라우드에 있고 Single Sign-On을 지원하는 경우 Microsoft Entra ID에서 애플리케이션으로 직접 Single Sign-On을 구성합니다.

      애플리케이션 지원 다음 단계
      OpenID Connect (오픈아이디 커넥트) OpenID Connect OAuth 애플리케이션 추가
      SAML 2.0 애플리케이션을 등록한 다음, SAML 엔드포인트 및 Microsoft Entra ID 인증서로 애플리케이션을 구성합니다.
      SAML 1.1 SAML 기반 애플리케이션 추가

    • SAP GUI를 사용하는 SAP 애플리케이션인 경우 싱글 사인온을 위해 SAP Secure Login Service 의 통합을 사용하여 Microsoft Entra를 통합하거나, Microsoft Entra Private Access 의통합을 사용할 수 있습니다.

    • 그렇지 않은 경우 Single Sign-On을 지원하는 온-프레미스 또는 IaaS 호스팅 애플리케이션인 경우 애플리케이션 프록시를 통해 Microsoft Entra ID에서 애플리케이션으로 Single Sign-On을 구성합니다.

      애플리케이션 지원 다음 단계
      SAML 2.0 애플리케이션 프록시 배포하고 SAML SSO 애플리케이션 구성
      IWA(통합 Windows 인증) 애플리케이션 프록시배포하고, Windows 통합 인증 SSO애플리케이션을 구성하고, 프록시를 제외한 애플리케이션의 엔드포인트에 대한 액세스를 방지하도록 방화벽 규칙을 설정합니다.
      헤더 기반 인증 애플리케이션 프록시를 배포하고 헤더 기반 SSO에 대한 애플리케이션을 구성합니다.

  4. 애플리케이션이 SAP BTP에 있는 경우 Microsoft Entra 그룹을 사용하여 각 역할의 멤버 자격을 유지할 수 있습니다. BTP 역할 컬렉션에 그룹을 할당하는 방법에 대한 자세한 내용은 SAP BTP 대한 액세스 관리참조하세요.

  5. 애플리케이션에 여러 역할이 있는 경우 각 사용자는 애플리케이션에 하나의 역할만 있고 애플리케이션은 Microsoft Entra ID를 사용하여 사용자의 단일 애플리케이션별 역할을 애플리케이션에 로그인하는 사용자의 클레임으로 보낸 다음 애플리케이션의 Microsoft Entra ID에서 해당 앱 역할을 구성한 다음 각 사용자를 애플리케이션 역할에 할당합니다. 앱 역할 UI 사용하여 해당 역할을 애플리케이션 매니페스트에 추가할 수 있습니다. Microsoft 인증 라이브러리를 사용하는 경우 액세스 제어를 위해 애플리케이션 내에서 앱 역할을 사용하는 방법에 대한 코드 샘플 있습니다. 사용자가 동시에 여러 역할을 가질 수 있는 경우 액세스 제어를 위해 앱 매니페스트의 앱 역할을 사용하는 대신 토큰 클레임 또는 Microsoft Graph를 통해 사용할 수 있는 보안 그룹을 확인하는 애플리케이션을 구현할 수 있습니다.

  6. 애플리케이션에서 프로비저닝을 지원하는 경우 할당된 사용자 및 그룹의 프로비저닝 Microsoft Entra ID에서 해당 애플리케이션으로 구성합니다. 프라이빗 또는 사용자 지정 애플리케이션인 경우 애플리케이션의 위치 및 기능에 따라 가장 적합한 통합을 선택할 수도 있습니다.

  7. 애플리케이션이 Microsoft Graph를 사용하여 Microsoft Entra ID에서 그룹을 쿼리하는 경우, 애플리케이션이 테넌트에서 데이터를 읽을 수 있도록 적절한 권한을 애플리케이션에 부여하려면 애플리케이션에 동의가 필요합니다.

  8. 애플리케이션 에 할당된 사용자만 애플리케이션에 접근할 수 있도록 설정합니다. 이 설정은 조건부 액세스 정책을 사용하도록 설정하기 전에 사용자가 실수로 MyApps에서 애플리케이션을 보고 애플리케이션에 로그인하는 것을 방지합니다.

초기 액세스 검토 수행

조직에서 이전에 사용하지 않은 새 애플리케이션이므로 기존 액세스 권한이 없거나 이 애플리케이션에 대한 액세스 검토를 이미 수행한 경우 다음 섹션으로 건너뜁니다.

그러나 애플리케이션이 이미 사용자 환경에 있는 경우 사용자는 과거에 수동 또는 대역 외 프로세스를 통해 액세스 권한을 얻었을 수 있습니다. 해당 사용자를 검토하여 액세스가 여전히 필요하고 적절한지 확인해야 합니다. 더 많은 사용자가 액세스를 요청할 수 있도록 정책을 사용하도록 설정하기 전에 애플리케이션에 대한 액세스 권한이 이미 있는 사용자의 액세스 검토를 수행하는 것이 좋습니다. 이 검토는 모든 사용자가 한 번 이상 검토되어 지속적인 액세스 권한이 있는지 확인하는 기준을 설정합니다.

  1. 사용자 액세스 검토를 준비하기 위해 애플리케이션 에 대한단계를 따르십시오.
  2. 애플리케이션이 Microsoft Entra ID 또는 AD를 사용하지 않았지만 프로비전 프로토콜을 지원하거나 기본 SQL 또는 LDAP 데이터베이스가 있는 경우 기존 사용자를 가져오고 애플리케이션 역할 할당을 만듭니다.
  3. 애플리케이션이 Microsoft Entra ID 또는 AD를 사용하지 않고 프로비저닝 프로토콜을 지원하지 않는 경우 애플리케이션에서 사용자 목록을 가져오고 각 사용자에 대한 애플리케이션 역할 할당을 만들있습니다.
  4. 애플리케이션이 AD 보안 그룹을 사용하는 경우 해당 보안 그룹의 멤버 자격을 검토해야 합니다.
  5. 애플리케이션에 자체 디렉터리 또는 데이터베이스가 있고 프로비저닝을 위해 통합되지 않은 경우 검토가 완료되면 애플리케이션의 내부 데이터베이스 또는 디렉터리를 수동으로 업데이트하여 거부된 사용자를 제거해야 할 수 있습니다.
  6. 애플리케이션이 AD 보안 그룹을 사용하고 AD에서 해당 그룹을 만든 경우 검토가 완료되면 AD 그룹을 수동으로 업데이트하여 거부된 사용자의 멤버 자격을 제거해야 합니다. 그런 다음, 액세스 권한이 자동으로 제거되지 않도록 애플리케이션을 업데이트하여 Microsoft Entra ID로 만든 AD 그룹을 사용하고 microsoft Entra ID 다시 작성된AD 그룹에서 Microsoft Entra 그룹으로 멤버 자격을 이동한 쓰기 저장 그룹을 AD 그룹의 유일한 구성원으로중첩할 수 있습니다.
  7. 검토가 완료되고 애플리케이션 액세스가 업데이트되거나 사용자가 액세스할 수 없는 경우 다음 단계로 계속 진행하여 애플리케이션에 대한 조건부 액세스 및 권한 관리 정책을 배포합니다.

이제 기존 액세스를 검토하도록 하는 기준이 있으므로, 조직의 정책을 배포하여 진행 중인 액세스 및 새 액세스 요청을 처리할 수 있습니다.

다음 단계