인증서 및 키

아티클
11/09/2015

업데이트: 2015년 6월 19일

Azure에 적용합니다.

Microsoft Azure Active Directory Access Control(Access Control 서비스 또는 ACS라고도 함)는 토큰에 서명하고 암호화하는 두 가지 방법, 즉 프라이빗 키를 사용하는 X.509 인증서와 256비트 대칭 키를 제공합니다. 네임스페이스의 모든 신뢰 당사자 응용 프로그램 또는 특정 신뢰 당사자 응용 프로그램에 대해 각 인증서나 키로 토큰에 서명하도록 구성할 수 있으며, 인증서 및 키가 기본이나 보조로 설정되도록 지정할 수 있습니다. 토큰 서명, 암호화 및 암호 해독 인증서 및 키를 추가하고 구성하려면 ACS 관리 서비스 또는 ACS 관리 포털을 사용합니다.

토큰 서명

ACS는 X.509 인증서(프라이빗 키 포함) 또는 256비트 대칭 키로 발급되는 모든 보안 토큰에 서명합니다. 서명 자격 증명 유형(인증서 또는 키)을 선택하는 것은 ACS에서 발급한 토큰에 대해 선택한 토큰 형식에 따라 달라집니다. 자세한 내용은 신뢰 당사자 애플리케이션의 "토큰 서명"을 참조하세요. 만들 서명 인증서 유형을 선택할 때는 다음 사항을 고려하세요.

SAML 토큰은 X.509 인증서로 서명됩니다. SAML은 WIF(Windows Identity Foundation)에서 작성하는 응용 프로그램에 사용되는 기본 토큰 형식입니다. WS-Federation, WS-Trust 등의 여러 프로토콜을 통해 SAML 토큰을 발급할 수 있습니다.
SWT 토큰은 256비트 대칭 키로 서명됩니다. SWT 토큰은 OAuth WRAP, WS-Federation 등의 여러 프로토콜을 통해 발급할 수 있습니다.
JWT 토큰은 X.509 인증서나 256비트 대칭 키로 서명할 수 있습니다. JWT 토큰은 WS-Federation, WS-Trust 및 OAuth 2.0 등의 여러 프로토콜을 통해 발급할 수 있습니다.

네임스페이스 또는 전용 인증서 및 키

서명 인증서 또는 대칭 키를 구성하여 전체 Access Control 네임스페이스 또는 네임스페이스의 특정 신뢰 당사자 애플리케이션에만 사용할 수 있습니다. 이들 항목 간의 차이는 다음과 같습니다.

네임스페이스 Access Control - 서명 인증서 또는 키가 전체 Access Control 네임스페이스에 대해 구성된 경우 ACS는 인증서 또는 키를 사용하여 애플리케이션별 인증서 또는 키가 없는 이 네임스페이스의 모든 신뢰 당사자 애플리케이션에 대한 토큰에 서명합니다. 네임스페이스 범위 인증서는 ACS WS-Federation 메타데이터에 서명하는 데도 사용됩니다.
전용 - 특정 신뢰 당사자 애플리케이션에 사용할 서명 인증서 또는 키를 구성하는 경우 ACS는 서명 인증서 또는 키를 사용하여 지정된 신뢰 당사자 애플리케이션에 전달된 토큰에만 서명합니다.

전용 대칭 키를 만들거나 입력하는 경우 ACS는 전용 키를 사용하여 애플리케이션에 대한 토큰을 서명합니다. 전용 키가 만료되고 교체되지 않으면 ACS는 Access Control 네임스페이스에 대칭 키를 사용하여 애플리케이션에 대한 토큰에 서명합니다.

참고

최상의 보안을 유지하려면 대칭 키를 사용할 때 각 신뢰 당사자 응용 프로그램에 대해 전용 키를 만드세요. X.509 인증서는 Access Control 네임스페이스의 여러 애플리케이션에서 안전하게 공유할 수 있습니다.
Microsoft 관리 신뢰 당사자 응용 프로그램을 관리되는 네임스페이스에 추가할 경우(예: 서비스 버스 네임스페이스에 서비스 버스 신뢰 당사자 응용 프로그램 추가) 응용 프로그램 특정(전용) 인증서나 키를 사용하지 마세요. 대신, 관리되는 네임스페이스의 모든 응용 프로그램에 대해 구성된 인증서와 키를 사용하는 ACS 옵션을 선택하세요. 그 이외의 모든 신뢰 당사자 응용 프로그램의 경우 응용 프로그램 특정 인증서 및 키를 사용합니다. 자세한 내용은 관리되는 네임스페이스를 참조하세요.
Access Control 네임스페이스에 대한 X.509 인증서를 사용하여 JWT 토큰에 서명하는 신뢰 당사자 애플리케이션을 구성하는 경우 Access Control 네임스페이스 인증서에 대한 링크와 Access Control 네임스페이스 키에 대한 링크가 ACS 관리 포털의 신뢰 당사자 애플리케이션 페이지에 표시됩니다. 그러나 ACS는 네임스페이스 인증서만 사용하여 신뢰 당사자 애플리케이션에 대한 토큰에 서명합니다.

서명 인증서는 일반적으로 네임스페이스의 모든 신뢰 당사자 응용 프로그램에 대해 토큰에 서명하는 데 사용됩니다. 네임스페이스 서명 인증서의 공개 키 구성 요소는 ACS WS-Federation 메타데이터에 게시되므로 신뢰 당사자 애플리케이션이 구성을 자동화할 수 있습니다. 특정 신뢰 당사자 애플리케이션에만 할당된 인증서의 공개 키는 ACS WS-Federation 메타데이터에 존재하지 않으며 신뢰 당사자 애플리케이션의 서명 인증서에 대한 독립적인 제어가 필요한 경우에만 사용됩니다.

기본 인증서 및 키

ACS에서는 여러 인증서와 키를 유지 관리할 수 있지만 지정된 인증서 및 키만 사용하여 토큰에 서명할 수 있습니다. 서명하는 데 사용하도록 지정된 인증서 및 키를 기본 인증서 및 키라고 합니다.

인증서나 키를 기본으로 지정하려면 인증서나 키의 해당 페이지에서 기본으로 만들기 항목을 선택합니다. 여러 인증서를 기본으로 지정하려면 다른 인증서나 키의 해당 페이지에서 기본으로 만들기 항목을 선택합니다. 이렇게 하면 ACS는 기존 기본 인증서 또는 키를 기본이 아닌 인증서로 자동으로 강등합니다.

하나 이상의 인증서나 키가 기본으로 설정된 경우 기본 인증서나 키가 잘못되었거나 만료된 경우에도 관리자에 의해 보조 인증서나 키가 기본 상태로 승격될 때까지 서명 시 비기본 인증서 및 키가 사용되지 않습니다. 그러나 인증서(또는 키)가 기본이 아닌 경우 ACS는 가장 일찍 유효한 시작 날짜가 있는 기본이 아닌 인증서를 사용합니다.

주 인증서와 기본 인증서가 아닌 인증서의 공개 키 구성 요소는 ACS WS-Federation 메타데이터에 게시되어 프로그래밍 방식 인증서 롤오버를 사용하도록 설정합니다. 그러나 ACS는 기본 인증서 및 키만 사용하여 토큰에 서명합니다.

서명 키의 개시 날짜 및 만료 날짜

256비트 대칭 서명 키를 추가할 때는 개시 날짜와 만료 날짜도 지정해야 합니다. 개시 날짜는 해당 키가 적용되는 날짜를 나타냅니다. 만료 날짜는 해당 키가 만료되어 더 이상 토큰에 서명하는 데 사용되지 않는 날짜를 나타냅니다.

토큰 암호화

ACS에서 ACS가 신뢰 당사자 애플리케이션에 발급하는 SAML 1.1 또는 SAML 2.0 토큰을 암호화하도록 선택할 수 있습니다.

중요

ACS는 SWT 또는 JWT 토큰의 암호화를 지원하지 않습니다.

WS-Trust 프로토콜을 통해 소유 증명 토큰을 사용하는 웹 서비스인 경우에는 토큰 암호화가 필요합니다. ACS를 사용하여 이러한 신뢰 당사자 애플리케이션에 대한 인증을 관리하는 경우 이 신뢰 당사자 애플리케이션에 대한 모든 ACS 발급 토큰을 암호화해야 합니다. 기타 모든 시나리오에서는 필요한 경우 토큰을 암호화하면 됩니다.

ACS는 공개 키(.cer 파일)가 포함된 X.509 인증서를 사용하여 SAML 토큰을 암호화합니다. 그런 다음 해당 X.509 인증서에 대해 개인 키를 사용하는 신뢰 당사자 응용 프로그램에서 토큰을 받아서 암호를 해독합니다. 자세한 내용은 신뢰 당사자 애플리케이션의 "토큰 암호화"를 참조하세요.

토큰 암호 해독

ACS는 WS-Federation ID 공급자의 암호화된 토큰을 수락할 수 있습니다. WS-Federation ID 공급자는 ACS에서 WS-Federation 메타데이터를 가져올 때 X.509 인증서의 공개 키를 수신하고 이 공개 키를 사용하여 ACS로 전달되는 보안 토큰을 암호화합니다. ACS는 이 X.509 인증서의 프라이빗 키를 사용하여 토큰의 암호를 해독합니다. 자세한 내용은 방법: ID 공급자로 AD FS 2.0 구성을 참조하세요.

기본 토큰 암호 해독 인증서

신뢰 당사자 애플리케이션 또는 Access Control 네임스페이스에 대해 여러 토큰 암호 해독 인증서를 유지할 수 있습니다. 인증서를 기본 인증서로 지정하는 경우 ACS는 해당 인증서를 사용하여 WS-Federation ID 공급자의 토큰을 해독하고 기본 인증서 사용 시도가 실패하는 경우에만 기본이 아닌 인증서를 사용합니다.

암호 해독 인증서를 기본으로 지정하려면 인증서의 해당 페이지에서 기본으로 만들기 항목을 선택합니다. 다른 인증서를 기본으로 지정하려면 해당 인증서의 페이지에서 기본으로 만들기 항목을 선택합니다. 이렇게 하면 ACS는 기존 기본 암호 해독 인증서를 기본이 아닌 인증서로 자동으로 강등합니다.

X.509 인증서 파일에 대한 ACS 제한

ACS에서 서비스 ID를 만들거나 ID 공급자의 서명의 유효성을 검사하거나 SAML 토큰을 암호화할 때 공개 키(.cer 파일)만 포함하는 X.509 인증서를 사용할 수 있습니다. 공개 키(.cer 파일)만 포함하는 X.509 인증서 파일은 ACS와 함께 사용하려면 DER로 인코딩되어야 합니다. 현재 Base64 인코딩 인증서 파일은 지원되지 않습니다. ACS에 base64로 인코딩된 인증서를 업로드하면 ACS에서 해당 인증서가 필요한 들어오는 토큰을 받으면 유효성 검사 오류가 발생합니다.

ACS에서 X.509 인증서는 자체 서명되거나 서명되어 공용 인증 기관에 직접 연결되어야 합니다. ACS는 프라이빗 인증 기관에서 발급한 인증서에는 작동하지 않습니다.

참고

ACS로 가져온 X.509 세리미네이트는 만료되지 않아야 합니다.

X.509 인증서 얻기

여러 가지 방법으로 토큰 서명, 토큰 암호화 또는 암호 해독용 X.509 인증서를 얻을 수 있습니다. 사용하는 방법은 조직에서 사용 가능한 도구 및 요구 사항에 따라 달라집니다.

상업용 인증 기관 - 상업용 인증 기관에서 X.509 인증서를 구입할 수 있습니다.

Self-Signed 인증서 생성 - ACS와 함께 사용할 자체 서명된 인증서를 생성할 수 있습니다. Windows 기반 운영 체제를 실행하는 경우 Microsoft Windows 소프트웨어 개발 키트(https://go.microsoft.com/fwlink/?LinkID=214104)에 포함된 도구인 MakeCert.exe 사용하여 자체 서명된 인증서를 생성할 수 있습니다.

예를 들어 다음 명령은 개인 인증서 저장소에서 자체 서명된 인증서를 생성합니다.

MakeCert.exe -r -pe -n "CN=<service_namespace_name>.accesscontrol.windows.net" -sky exchange -ss my -len 2048 –e <1 year from today>

여기서 <service_namespace_name> Access Control 네임스페이스의 이름입니다.

그런 다음 개인 저장소에서 프라이빗 키를 .pfx 파일로 내보낸 다음 ACS 관리 포털을 사용하여 ACS에 업로드할 수 있습니다.

자체 서명된 인증서 내보내기

이 지침에서는 Windows 8, Windows Server 2012 또는 실행하는 컴퓨터에서 자체 서명된 인증을 내보내는 방법을 설명합니다.

자체 서명된 인증서를 내보내려면

MMC.exe 시작하고 인증서 스냅인 을 MMC 콘솔에 추가합니다.
인증서 - 현재 사용자, 개인을 두 번 클릭한 후 인증서를 두 번 클릭합니다.
인증서를 마우스 오른쪽 단추로 클릭하고 모든 작업을 클릭한 다음 내보내기를 클릭합니다.
인증서 내보내기 마법사 시작 페이지에서 다음을 클릭합니다.
개인 키 내보내기 페이지에서 예, 개인 키를 내보냅니다를 클릭하고 다음을 클릭합니다.
파일 내보내기 형식 페이지에서 개인 정보 교환 – PKCS #12(.PFX)를 클릭합니다.
암호 필드에 암호 및 확인 암호를 입력한 후 다음을 클릭합니다.
파일 이름 필드에 경로 및 파일 이름 확장명이 .pfx인 파일 이름을 입력한 후 다음을 클릭합니다.
Finish를 클릭합니다.