CXone의 인증 및 권한 부여

이 페이지는 CXone에서 인증 및 권한 부여가 작동하는 방식에 대한 특정 정보를 제공합니다. 이러한 개념을 처음 접하는 경우 먼저 인증 및 권한 부여의 내용과 용어에 대한 기본적인 지식을 이해해야 합니다.

이 자료를 검토한 후에는 아래 작업을 수행할 수 있습니다.

사용자가 CXone 등의 애플리케이션 제품군에 로그인할 때 일반적으로 다음 두 단계가 설명된 순서대로 발생합니다.

인증—사용자가 자신이 주장하는 사용자가 맞습니까?
권한 부여 - 인증된 사용자에게 요청한 액세스 권한을 부여해야 합니까?

모든 사용자는 반드시 인증 및 권한 부여를 받아야 CXone에 액세스할 수 있습니다.

사용자란 사람 또는 애플리케이션이 될 수 있습니다. 예를 들어, 사용자 계정을 통해 챗봇과 가상 도우미를 실행하기도 합니다. 대부분의 애플리케이션 제품군은 사람과 가상 사용자에 대해 동일한 프로세스를 사용합니다. 인증 및 권한 부여에 대한 이 온라인 도움말 페이지에서 사용자라는 용어는 사람과 애플리케이션에 모두 적용됩니다. 차이가 있는 경우 명확하게 설명되어 있습니다.

인증은 설정하기가 복잡하고 테스트 및 검증하기도 어려울 수 있습니다. CXone에서 인증을 설정하려면 다음 사항을 이해해야 합니다.

CXone의 인증 작동 방식
기본 제공 CXone ID 공급자
외부 ID 공급자
인간 사용자 인증과 애플리케이션 사용자 인증의 차이점

또한 CXone 플랫폼에서 권한 부여가 작동하는 방식도 알아야 합니다.

이 그림은 CXone이(가) 사용자를 인증하고 권한을 부여하는 방식을 나타냅니다.

사용자가 지원되는 웹 브라우저를 통해 CXone에 액세스합니다.
CXone이(가) 사용자의 로그인 자격 증명을 요청합니다.
사용자가 자격 증명을 제공합니다.
CXone이(가) ID 공급자(IdP)를 통해 이를 확인합니다. CXone에는 기본 제공 IdP가 있지만 외부 IdP와도 작동할 수 있습니다.
사용자가 인증되면 CXone 인증 서버가 CXone 플랫폼에 대한 액세스를 제공합니다. CXone은(는) 외부 인증 시스템을 지원하지 않습니다.

기본 제공 ID 공급자를 사용한 인증

기본 제공 CXone IdP는 사용자 이름과 암호로 사용자를 인증합니다. 각 사용자 이름은 해당 조직에 고유해야 합니다. 선택적으로 다단계 인증(MFA)을 사용하여 보안 계층을 추가할 수 있습니다.

애플리케이션 사용자

애플리케이션이 CXone 기능에 액세스해야 하는 경우가 있습니다. CXone은(는) 봇 및 대화형 가상 도우미(IVA) 등 이러한 애플리케이션을 사용자로 취급합니다. 애플리케이션 사용자는 기본 제공 인증을 통해서만 지원됩니다. 또한 애플리케이션 사용자는 로그인 인증기를 사용하지 않습니다. 대신 액세스 키를 사용합니다.

기본 제공 인증을 통한 사용자 로그인

사용자에게 먼저 사용자 이름을 요청하는 화면이 표시됩니다. CXone은(는) 사용자 이름을 알 때까지 추가 자격 증명을 요청할 수 없습니다. CXone은(는) 로그인하는 사용자를 알게 된 경우에만 암호 또는 MFA 토큰을 요청할 수 있습니다.

사용자가 사용자 이름을 입력하고 다음을 클릭하면 새 창이 나타나 사용자의 암호를 묻습니다. 사용자가 올바른 암호를 입력하고 로그인을 클릭하면 CXone이(가) 사용자를 인증하고 시스템에 대한 액세스 권한을 부여합니다.

이 창은 MFA를 사용하도록 구성된 사용자에게는 약간 다르게 보입니다. 사용자가 사용자 이름을 입력하고 다음을 클릭하면 새 창이 나타나 사용자의 암호 및 MFA 토큰을 요구합니다. 사용자는 올바른 암호와 유효한 토큰을 입력하고 로그인을 클릭합니다. CXone은(는) 사용자를 인증하고 시스템에 대한 액세스 권한을 부여합니다.

기본 제공 인증을 통한 암호 관리

암호 조건은 로그인 인증기에서 사용자 정의할 수 있습니다. 로그인 인증기를 사용하여 다음 항목을 제어할 수 있습니다.

암호에 필요한 문자 수
암호에 필요한 문자 형식
사용자가 암호를 재설정해야 하는 기간(일)
계정이 잠길 때까지 허용되는 잘못된 암호 시도 횟수
사용자가 재사용하지 못하도록 CXone이(가) 기억해 두는 암호의 개수

CXone에서는 암호가 표시되지 않습니다. 개인정보 보호 및 보안을 위해 암호는 내부적으로 유지 관리되며 암호 분실 또는 암호 재전송 절차를 통해서만 변경할 수 있습니다. 사용자는 암호 로그인 화면의 링크를 사용하여 화면상의 지침을 따를 수 있습니다. 사용자는 암호가 변경된 경우 이를 알리는 이메일을 받게 됩니다.

CXone은(는) 사용자 정의 로그인 인증기가 필요하지 않은 경우에 사용할 수 있는 기본 로그인 인증기와 함께 제공됩니다. 그렇다 해도 이 기본 인증기를 사용하려는 사용자에 할당해야 합니다.

사용자 정의 로그인 인증기는 원하는 수만큼 설정할 수 있습니다. 예를 들어 중요한 정보에 액세스하는 사용자에게는 더 복잡한 암호를 요구할 수 있습니다. 사용자 계정마다 인증 요구 사항을 다르게 하려면 새 로그인 인증기를 생성해야 합니다. 인증기에 대한 변경 사항은 할당된 사용자가 다음에 로그인할 때 적용됩니다.

사용자 정의 로그인 인증기를 사용하여 다단계 인증(MFA)을 설정할 수도 있습니다. MFA는 또 다른 인증 계층을 추가하여 보안을 강화합니다. 예를 들어 사용자 이름과 암호로 사용자를 인증합니다. 그런 다음 모바일 장치에 전송된 코드로 한 번 더 인증을 받게 할 수 있습니다. 이러한 코드는 물리적 토큰을 포함하고 있지는 않지만, 일반적으로 MFA 토큰이라고 합니다.

CXone은(는) 두 가지 주요 MFA 유형을 모두 지원합니다.

시간 기반— 일반적으로 Google과 같은 소프트웨어 인증기에서 사용합니다.
카운터 기반— 일반적으로 하드웨어 토큰에서 사용합니다.

단일 확인란의 로그인 인증기에 대해 MFA를 활성화할 수 있습니다. 단, 사용자와 그 MFA 설정, 그 ID에 대한 특정 정보는 개별 직원 계정에 유지됩니다.

로그인 인증기와 보안 프로필은 완전히 별개입니다. 즉, 직원의 인증 방법은 CXone에서 직원이 액세스할 수 있는 대상과는 아무 관련이 없습니다.

외부 ID 공급자를 사용한 인증

다른 사이트의 계정으로 시스템에 로그인하는 경우 외부 인증을 사용하게 됩니다. 예를 들어 자신의 휴대폰에서 Google 계정으로 앱에 로그인할 수 있습니다.

페더레이션이라고도 하는 외부 인증은 외부의 ID 공급자(IdP)를 사용하여 사용자를 인증합니다. 외부 IdP는 CXone IdP와 함께 작동하여 사용자를 인증합니다. 두 IdP가 함께 작동하기 위해서는 인증 프로토콜을 이용해야 합니다.

외부 IdP

CXone은(는) 호스팅 및 클라우드 서비스 ID 공급자를 모두 지원합니다.

사용자는 ID 공급자를 숙지하고 있어야 합니다. 그렇지 않은 경우 사내 인증 관리팀으로 문의하십시오. 페더레이션 설정에는 숙련된 직원의 협조가 필요할 수 있습니다. 조직에 CXone와(과) 같은 시스템을 ID 공급자와 통합하는 프로세스가 수립되어 있을 수 있습니다. 이러한 프로세스를 따르고 특정 보안 요구 사항을 충족하는 것은 사용자의 책임입니다. NICE CXone 팀은 그러한 여정에서 사용자를 지원합니다.

인증 프로토콜

인증 프로토콜은 서로 다른 IdP 간의 통신 및 트러스트를 설정합니다. CXone은(는) 다음 인증 프로토콜을 지원합니다.

OpenID Connect
SAML 2.0

OpenID Connect은(는) 기능이 더 많이 있으며 지원하기가 더 쉽습니다. 주요 이점은 다음과 같습니다.

업계 표준 기술
사용자에게 투명하고 끊김 없는 IdP 통합
다양한 MFA(다단계 인증) 옵션 활성화
플랫폼 서비스 모델을 위한 확장 가능 기반

OpenID Connect은(는) 업계 표준인 JWKS를 사용하여 공용/개인 인증서 서명으로 인증을 확인합니다. 따라서 OpenID Connect 구성 시 공용 인증서를 얻는 방법을 결정합니다. 인증서 발급자와의 트러스트는 클라이언트 식별자와 암호를 사용하여 설정됩니다.

SAML 2.0은(는) 오래된 기술이며, 통합 시 문제를 일으킬 수 있습니다. 그러나 현재는 OpenID Connect보다 널리 사용되고 있습니다. 조직에 사용할 프로토콜에 대한 지침이 있을 수 있습니다. 전체적으로, 두 기술은 사용자 경험 및 기본 보안 레벨이 유사합니다.

OpenID Connect 및 SAML 2.0은(는) 모두 서비스 공급자(SP) 시작 인증 절차를 지원합니다. 이는 친숙한 절차로, 대다수 앱과 웹 사이트에서 사용되는 모델입니다. 다음과 같은 사용자 경험을 제공합니다.

사용자가 CXone에 자격 증명을 입력합니다(로그인).
CXone이(가) 기본 IdP로 외부 IdP와 통신하여 사용자 ID를 확인합니다.
CXone은(는) 기본 권한 부여를 사용하여 인증된 사용자의 액세스 레벨을 확인합니다.
CXone은(는) 인증 및 권한 부여를 받은 사용자에게 올바른 액세스를 제공합니다.

SAML 2.0은(는) 이보다는 덜 일반적인 ID 공급자(IdP) 시작 절차도 지원합니다. 이 절차에서 사용자는 ID 공급자와 함께 자격 증명을 입력합니다. 그러면, ID 공급자가 CXone을(를) 시작합니다.

SAML 2.0의 경우 CXone은 어설션이 아닌 메시지/응답 서명만 지원합니다.

IdP 시작 흐름은 전체 CXone 제품군이 아닌 단일 애플리케이션에 적용됩니다. 예를 들어 이 흐름을 사용하여 기본 사용자 인터페이스 애플리케이션을 시작할 수 있지만 Studio와 같은 다른 애플리케이션을 시작하는 데 사용할 수는 없습니다. 전체 제품군이 원활하게 작동하려면 SP 시작 흐름이 필요합니다.

사용자는 이러한 인증 절차 중 하나 또는 둘 모두에 익숙할 수 있습니다. SAML 2.0을(를) 사용하는 경우 각 절차에 해당되는 제한 사항을 알고 있어야 합니다. 이 내용은 다음 섹션에서 자세히 설명합니다. OpenID Connect은(는) 항상 SP 시작 절차를 사용합니다.

CXone은(는) 일부 인증 프로토콜에서 제공하는 추가 암호화를 지원하지 않습니다.

구성 세부 정보는 선택한 IdP 및 인증 프로토콜에 따라 다릅니다. IdP와 인증 프로토콜의 모든 조합을 다룰 수는 없지만 몇 가지 일반적인 시나리오가 아래에 설명되어 있습니다.

조합 평가

CXone 제품군은 애플리케이션, 외부 IdP 및 인증 프로토콜의 모든 조합을 지원하지 않습니다. 어떤 경우에는 지원이 존재하지 않습니다. 해결 방법이 제한적인 경우도 있습니다. 모든 조합과 시나리오에 대한 잠재적 문제를 설명하기란 쉽지 않으므로, ID 공급자와 함께 테스트 설정을 수행해야 합니다. 테스트에는 다양한 사용 사례와 사용자 절차를 고려해야 합니다. 다음 표가 평가를 수행하는 데 도움이 될 수 있습니다.

CXone 애플리케이션	외부 IDP	인증 프로토콜	제한 사항 및 해결 방법
CXone 플랫폼 및 모든 애플리케이션	All	All	클레임 암호화를 지원하지 않습니다.
CXone 플랫폼 및 모든 애플리케이션	All	SAML 2.0	메시지 서명만 지원됩니다. 응답에는 공용 인증서가 포함되어야 합니다.
CXone 플랫폼	Azure AD	SAML 2.0	IdP 시작 절차만 지원됩니다.

기본 웹 애플리케이션만 IdP 시작 SAML 2.0 흐름을 지원합니다. Studio 또는 다양한 상담원 애플리케이션에 액세스해야 하는 사용자는 기본 제공 인증 또는 SP 시작 흐름을 사용해야 합니다.

트러스트 설정

ID 공급자가 서로 통신하려면 사전에 트러스트되어 있어야 합니다. 각 공급자에게 상대 공급자에 대한 정보가 있어야 합니다. 필요한 정보는 인증 프로토콜에 따라 다릅니다. 정보를 얻는 방법은 IdP에 따라 다릅니다.

OpenID Connect의 트러스트

CXone 계정 담당자는 OpenID Connect를 사용하여 CXone 사업부 고급 조직 그룹화는 CXone 환경을 위해 기술 지원, 청구 및 글로벌 설정을 관리하는 데 사용됩니다. 와 외부 IdP 간에 신뢰할 수 있는 관계를 구성하기 위해 함께 작동합니다.

OpenID Connect의 트러스트는 관계를 구성하는 데 필요한 다음 값을 포함합니다.

발급자—이 값은 URL과 유사하게 보입니다. 발급자 값은 외부 IdP에 따라 다르지만 URL과 비슷합니다. 예를 들어 Google은 외부 IdP로 작동할 수 있으며, OpenID Connect을(를) 지원합니다. Google 발급자는 https://accounts.google.com입니다. 대다수 외부 IdP 공급자는 IdP의 기본 URL 끝에 “.well-known/openid-configuration”을 추가하여 발급자 URL을 검색할 수 있도록 합니다. 이는 주로 IdP의 추가적인 중요 정보를 제공합니다. 다음 이미지는 Facebook에서 이러한 방식으로 제공하는 정보의 유형을 보여줍니다(https://www.facebook.com/.well-known/openid-configuration).
클라이언트 식별자— 이 값은 CXone와(과) 함께 사용할 수 있도록 외부 IdP에서 할당합니다. 인증 시, IdP는 이를 통해 어떤 애플리케이션이 인증을 시도하는지 알 수 있습니다.
클라이언트 암호— 이 값은 인증의 보안을 보장하고 악의적인 행위자가 외부 IdP를 사용하여 CXone 사업부 에 인증할 수 없도록 합니다. CXone은(는) client_secret_basic 및 client_secret_post만 지원합니다.

SAML 2.0의 트러스트

SAML 2.0와(과)의 트러스트를 설정하는 데 사용되는 몇 가지 구성 매개변수가 있습니다. CXone 계정 담당자와 협력하여 이러한 매개변수를 사용하여 CXone 사업부 고급 조직 그룹화는 CXone 환경을 위해 기술 지원, 청구 및 글로벌 설정을 관리하는 데 사용됩니다. 와 외부 IdP 간에 신뢰할 수 있는 관계를 만듭니다.

필드	세부 정보
엔터티 ID	SAML 2.0 프로트콜을 사용할 때 외부 IdP가 입력을 요구할 수 있는, 사전에 채워진 편집 불가 글로벌 고유 ID입니다. IdP는 이를 SAML 2.0 요청 메시지에 발급자의 엔터티 ID로 포함시킵니다. Okta 및 OneLogin을 비롯한 일부 IdP에서는 해당 측에서 항목 ID를 구성할 필요가 없습니다. Salesforce를 포함한 다른 곳에서는 이를 요구합니다.
엔드포인트 URL	자신의 IdP에서 제공한 엔드포인트 URL입니다.
주장 URL	SAML 2.0 절차 설정 시 IdP에서 요구하는, 사전에 채워진 편집 불가 URL입니다. 이는 인증 주장을 수신하고 구문을 분석하기 위한 엔드포인트 URL로 사용됩니다. 이 ID를 자신의 IdP 구성에 입력해야 합니다. 보통 ACS URL 필드에 입력해야 합니다. 일부 IdP는 이를 ACS가 아닌 다른 이름으로 부릅니다. 예를 들어 Okta SAML 2.0 템플릿에서 단일 로그인 URL 입력란에 이 URL을 입력합니다.
인증서	IdP는 사용자에게 보안 인증서를 제공합니다.

애플리케이션의 인증

사용자와 애플리케이션은 매우 유사한 방식으로 인증됩니다. 애플리케이션은 액세스 키로 인증되지만 사용자는 사용자 이름과 암호로 인증된다는 점이 큰 차이입니다. 사용자와 달리 애플리케이션은 브라우저를 통해 상호작용할 필요가 없습니다. 애플리케이션은 백오피스 환경에서 작동할 수 있습니다.

사용자 대신 애플리케이션을 나타내는 사용자 프로필을 만들 수 있습니다. 이를 위해 사용자 프로필을 만들고 애플리케이션 이름을 따서 프로필 이름을 지정하고 액세스 키를 생성합니다. CXone은(는) 애플리케이션의 인증을 내부적으로 관리합니다. 이는 외부 ID 공급자로 인증할 수 없습니다.

CXone의 권한 부여

권한 부여는 사용자가 액세스할 수 있는 리소스를 확인하는 프로세스입니다. 리소스에는 애플리케이션, 파일, 데이터 등이 포함될 수 있습니다. 보안 프로필을 사용하여 리소스에 대한 사용자 액세스를 정의할 수 있습니다. CXone은 로그인 과정에서 자동으로 인증을 관리합니다. 인증된 사용자는 권한이 부여된 리소스에만 액세스할 수 있습니다.

사용자의 인증 방법은 권한 부여에 영향을 미치지 않습니다. CXone은(는) 모든 사용자에 대해 동일한 권한 부여 프로세스를 사용합니다. 액세스 키 또는 암호 중 어떤 방식으로 인증되었는지는 중요하지 않습니다.