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

  • 아티클

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

Microsoft Entra ID 거버넌스는 SAP R/3, SAP S/4HANA와 같은 잘 알려진 애플리케이션 및 OpenID 커넥트, 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 통합을 선택할 수도 있습니다.

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

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

  6. 애플리케이션이 Microsoft Graph를 사용하여 Microsoft Entra ID에서 그룹을 쿼리하는 경우 애플리케이션이 테넌트에서 읽을 수 있는 적절한 권한을 갖도록 동의합니다.

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

초기 액세스 검토 수행

이 애플리케이션은 조직에서 이전에 사용한 적이 없는 새 애플리케이션이므로 아무도 기존 액세스 권한을 갖고 있지 않습니다. 또는 이 애플리케이션의 액세스 검토를 이미 수행한 경우 다음 섹션으로 건너뜁니다.

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

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

기존 액세스 권한을 검토하도록 하는 기준이 마련되었으므로, 지속적인 액세스 및 신규 액세스 권한 요청에 대한 조직의 정책을 배포할 수 있습니다.

다음 단계