내보내기(0) 인쇄
모두 확장

인증서 및 키

게시: 2011년 4월

업데이트 날짜: 2014년 11월

적용 대상: Azure

Microsoft Azure Active Directory 액세스 제어(액세스 제어 서비스 또는 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 등의 여러 프로토콜을 통해 발급할 수 있습니다.

전체 액세스 제어 네임스페이스 또는 네임스페이스의 특정 신뢰 당사자 응용 프로그램 하나에 대해 사용할 서명 인증서나 대칭 키를 구성할 수 있습니다. 이들 항목 간의 차이는 다음과 같습니다.

  • 액세스 제어 네임스페이스 - 전체 액세스 제어 네임스페이스에 대해 서명 인증서 또는 키를 구성하면 ACS에서는 이 네임스페이스에서 응용 프로그램 특정 인증서나 키가 없는 모든 신뢰 당사자 응용 프로그램에 대해 이 인증서 또는 키를 사용하여 토큰에 서명을 합니다. 네임스페이스 범위 인증서는 ACS WS-Federation 메타데이터를 서명하는 데에도 사용됩니다.

  • 전용 - 특정 신뢰 당사자 응용 프로그램에 사용할 서명 인증서 또는 키를 구성하는 경우, ACS에서는 이 서명 인증서 또는 키를 사용하여 지정된 해당 신뢰 당사자 응용 프로그램으로만 배달된 토큰에 서명합니다.

    전용 대칭 키를 만들거나 입력하는 경우 ACS에서는 전용 키를 사용하여 해당 응용 프로그램에 대해 토큰에 서명합니다. 전용 키가 만료되었지만 대체되지 않은 경우 ACS에서는 액세스 제어 네임스페이스의 대칭 키를 사용하여 해당 응용 프로그램에 대해 토큰에 서명합니다.

note참고
  • 최상의 보안을 유지하려면 대칭 키를 사용할 때 각 신뢰 당사자 응용 프로그램에 대해 전용 키를 만드세요. X.509 인증서는 액세스 제어 네임스페이스의 여러 응용 프로그램에서 안전하게 공유할 수 있습니다.

  • Microsoft 관리 신뢰 당사자 응용 프로그램을 관리되는 네임스페이스에 추가할 경우(예: 서비스 버스 네임스페이스에 서비스 버스 신뢰 당사자 응용 프로그램 추가) 응용 프로그램 특정(전용) 인증서나 키를 사용하지 마세요. 대신, 관리되는 네임스페이스의 모든 응용 프로그램에 대해 구성된 인증서와 키를 사용하는 ACS 옵션을 선택하세요. 그 이외의 모든 신뢰 당사자 응용 프로그램의 경우 응용 프로그램 특정 인증서 및 키를 사용합니다. 자세한 내용은 관리되는 네임스페이스를 참조하세요.

  • 액세스 제어 네임스페이스에 대해 X.509 인증서를 사용하는 신뢰 당사자 응용 프로그램이 JWT 토큰에 서명하도록 구성할 경우 액세스 제어 네임스페이스 인증서 및 액세스 제어 네임스페이스 키에 대한 링크가 ACS 관리 포털의 신뢰 당사자 응용 프로그램 페이지에 표시됩니다. 단, ACS에서는 신뢰 당사자 응용 프로그램에 대해 네임스페이스 인증서만 사용하여 토큰에 서명합니다.

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

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

인증서나 키를 기본으로 지정하려면 인증서나 키의 해당 페이지에서 기본으로 만들기 항목을 선택합니다. 여러 인증서를 기본으로 지정하려면 다른 인증서나 키의 해당 페이지에서 기본으로 만들기 항목을 선택합니다. 이 작업을 수행하면 ACS에서는 기존의 기본 인증서 또는 키가 자동으로 보조로 강등됩니다.

하나 이상의 인증서나 키가 기본으로 설정된 경우 기본 인증서나 키가 잘못되었거나 만료된 경우에도 관리자에 의해 보조 인증서나 키가 기본 상태로 승격될 때까지 서명 시 비기본 인증서 및 키가 사용되지 않습니다. 단, 기본으로 설정된 인증서나 키가 없는 경우에는 ACS에서 개시 날짜가 가장 빠른 보조 인증서를 사용합니다.

기본 인증서와 보조 인증서의 공용 키 구성 요소는 모두 ACS WS-Federation 메타데이터에 게시되므로 프로그래밍 방식 인증서 롤오버가 가능하지만, ACS에서는 기본 인증서 및 키만 토큰에 서명하는 데 사용됩니다.

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

ACS에서는 ACS가 발급하는 SAML 1.1 또는 SAML 2.0 토큰을 암호화하여 신뢰 당사자 응용 프로그램으로 보내도록 선택할 수 있습니다.

Important중요
SWT 또는 JWT 토큰 암호화는 ACS에서 지원되지 않습니다.

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

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

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

신뢰 당사자 응용 프로그램 또는 액세스 제어 네임스페이스에 대해 여러 토큰 암호 해독 인증서를 유지 관리할 수 있습니다. 인증서를 기본으로 지정하면 ACS에서 해당 인증서를 사용하여 WS-Federation ID 공급자에서 토큰의 암호를 해독하며, 기본 인증서 사용 시도가 실패할 경우에만 보조 인증서를 사용합니다.

암호 해독 인증서를 기본으로 지정하려면 인증서의 해당 페이지에서 기본으로 만들기 항목을 선택합니다. 다른 인증서를 기본으로 지정하려면 해당 인증서의 페이지에서 기본으로 만들기 항목을 선택합니다. 이 작업을 수행하면 ACS에서는 기존의 기본 암호 해독 인증서가 자동으로 보조로 강등됩니다.

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

ACS에서 X.509 인증서는 자체 서명되거나 공인 인증 기관으로 직접 연결 또는 서명되어야 합니다. ACS에서는 사설 인증 기관에서 발급한 인증서는 사용할 수 없습니다.

note참고
ACS로 가져온 X.509 인증서는 만료되면 안 됩니다.

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

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

자체 서명된 인증서 생성 - ACS에서 사용할 자체 서명된 인증서를 직접 생성할 수 있습니다. Windows 기반 운영 체제를 실행하는 경우에는 Microsoft Windows 소프트웨어 개발 키트(http://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>은 액세스 제어 네임스페이스의 이름입니다.

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

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

  1. MMC.exe를 시작하고 MMC 콘솔에 인증서 스냅인을 추가합니다.

  2. 인증서 - 현재 사용자, 개인을 두 번 클릭한 후 인증서를 두 번 클릭합니다.

  3. 인증서를 마우스 오른쪽 단추로 클릭하고 모든 작업을 클릭한 다음 내보내기를 클릭합니다.

  4. 인증서 내보내기 마법사 시작 페이지에서 다음을 클릭합니다.

  5. 개인 키 내보내기 페이지에서 예, 개인 키를 내보냅니다.를 선택한 후 다음을 클릭합니다.

  6. 파일 내보내기 형식 페이지에서 개인 정보 교환 – PKCS #12(.PFX)를 클릭합니다.

  7. 암호 필드에 암호 및 확인 암호를 입력한 후 다음을 클릭합니다.

  8. 파일 이름 필드에 경로 및 파일 이름 확장명이 .pfx인 파일 이름을 입력한 후 다음을 클릭합니다.

  9. 마침을 클릭합니다.

ACS에서는 인증서 및 키의 시작 날짜 및 종료 날짜(날짜-시간)를 협정 세계시(UTC)로 평가합니다. 따라서 ACS에서는 키와 인증서가 로컬 컴퓨터의 현지 시간이나 다른 표준 시간대에서 유효하더라도 이를 유효하지 않다고 판단할 수 있습니다.

인증서나 키가 즉시 유효하도록 하려면 날짜를 UTC 시간을 조정하세요. 그렇지 않으면 키나 인증서가 여전히 유효하지 않다고 판단되어 ACS에서 토큰을 발급하지 못할 수 있습니다.

참고 항목

커뮤니티 추가 항목

추가
표시:
© 2015 Microsoft