서비스에서 EPA(확장된 인증 보호) 지원

아티클
10/18/2023

기능	적용 대상:
Epa	지원되는 모든 Windows OS
EPA 감사 모드	Windows Server 2019 Windows Server 2022 Windows Server 23H2

문제가 무엇입니까?

전달 공격이라고 하는 인증된 서비스에 대한 공격 클래스가 있습니다. 이러한 공격을 통해 악의적 사용자는 인증을 우회하고 다른 사용자 역할을 할 수 있습니다. 이는 인증 프로토콜 자체가 아니라 서비스에 대한 공격이므로 전달 공격을 저지하는 것은 인증된 서비스에 달려 있습니다.

전달 공격은 어떻게 작동합니까?

서비스 또는 애플리케이션이 API AcceptSecurityContext를 호출하여 클라이언트를 인증하면 클라이언트의 호출에서 받은 데이터 Blob을 InitializeSecurityContext에 전달합니다. 인증 프로토콜은 제공된 Blob이 표시된 사용자로부터 시작되었는지 확인하는 역할을 합니다. AcceptSecurityContext는 표시되지 않은 애플리케이션 메시지의 re기본der의 신뢰성에 대한 어설션을 만들 수 없습니다.

애플리케이션의 일반적인 보안 실수는 내부 인증 프로토콜 Blob의 성공적인 인증 후에 애플리케이션 트래픽을 인증된 것으로 처리하는 것입니다. 이는 가장 일반적으로 유선 프로토콜에 TLS를 사용하는 애플리케이션에서 발생합니다. TLS는 일반적으로 클라이언트 인증서를 사용하지 않습니다. 서버에 무결성 및 기밀성 보장을 제공하지만 인증은 제공하지 않습니다. 내부 인증은 클라이언트 인증을 제공하지만 해당 Blob에 대해서만 제공합니다. TLS 채널 또는 해당 채널에 포함된 애플리케이션 프로토콜의 re기본der를 인증하지 않습니다.

공격자는 공격자가 만든 요청을 사용하여 한 원본에서 인증 Blob을 삽입하여 전달 공격을 실행합니다. 예를 들어 공격자는 네트워크에서 인증 트래픽을 관찰하고 서버에 대한 자체 요청에 삽입할 수 있습니다. 이렇게 하면 공격자가 캡처된 인증 트래픽에서 클라이언트로 서버에 액세스할 수 있습니다.

여기서 주요 개념은 SSPI 인증 메시지가 유선으로 노출되도록 설계되었다는 것입니다. 비밀로 유지되지 않을 것으로 예상됩니다. 이는 TLS 채널 내에서 항상 기밀로 유지되는 전달자 토큰을 사용하는 많은 웹 기반 인증 체계와 다릅니다.

솔루션이란?

기본 솔루션은 인증 프로토콜의 세션 키를 사용하여 다른 트래픽에 서명하거나 암호화하는 것입니다(MakeSignature, EncryptMessage). 세션 키는 인증 프로토콜 교환 중에 암호화적으로 파생되므로 인증된 데이터 및 해당 키로 보호되는 모든 트래픽은 인증된 클라이언트에서 가져올 수 있습니다.

항상 옵션이 되는 것은 아닙니다. 경우에 따라 애플리케이션 프로토콜 메시지의 형식은 전달자 토큰용으로 설계된 표준에 의해 수정됩니다. 이 경우 채널 바인딩이라고도 하는 EPA(확장된 인증 보호)는 TLS/SSL 채널을 통한 전달을 방지할 수 있습니다.

EPA란?

EPA는 TLS 세션 키를 인증 프로토콜의 세션 키에 암호화하여 바인딩하여 TLS가 인증 프로토콜의 키와 동일한 클라이언트 인증을 제공할 수 있도록 합니다. 자세한 내용은 인증에 대한 확장 보호 개요를 참조하세요.

서비스 바인딩

EPA의 두 번째 부분을 서비스 바인딩이라고 합니다. 채널 바인딩과 달리, 이는 서비스에 암호화 보장을 제공하지 않으며 채널 바인딩이 불가능한 최후의 수단의 방어 역할을 합니다. 이 메커니즘을 사용하면 서버가 QueryContextAttributes를 호출하여 InitializeSecurityContext에 전달된 인증된 클라이언트 이름이 포함된 특성 SECPKG_ATTR_CLIENT_SPECIFIED_TARGET 검색할 수 있습니다.

예를 들어 TLS 종료 부하 분산 장치 뒤에 있는 서비스를 상상해 보십시오. TLS 세션 키에 액세스할 수 없으며 채널 바인딩에서만 클라이언트의 인증이 TLS 보호 서비스를 위한 것임을 확인할 수 있습니다. 클라이언트에서 제공하는 이름은 TLS 서버 인증서의 유효성을 검사하는 데 사용한 이름과 같아야 합니다. 클라이언트가 부하 분산 장치에서 서버 TLS 인증서와 일치하는 이름을 인증했는지 확인함으로써 서비스는 인증이 TLS 채널과 동일한 클라이언트에서 제공되었다는 높은 신뢰도를 얻습니다.

이 문서에서는 서비스 바인딩을 지원하는 방법을 설명하지 않습니다. 자세한 내용은 방법: 구성에서 서비스 바인딩 지정을 참조하세요.

EPA를 어떻게 지원합니까?

EPA를 적용할 때 서비스는 호환성 문제로 인해 클라이언트가 인증에 실패하는 것을 알 수 있습니다. 따라서 서비스에서 감사를 사용하도록 설정할 수 있는 EPA 감사 모드를 만들어 관리자가 EPA를 적용하기 전에 클라이언트가 응답하는 방식을 관찰할 수 있도록 합니다.

감사 모드를 지원하는 Microsoft 서비스 다음이 포함됩니다.

LDAP

참고 항목

아래에서 EPA 감사 기능을 사용하도록 설정하는 선택적 단계를 찾을 수 있습니다. EPA를 적용하지 않고 EPA 감사 기능을 사용하도록 설정해도 릴레이 공격으로부터 보호되지 않습니다. 감사 모드에서만 EPA를 먼저 사용하도록 선택한 서비스는 나중에 호환되지 않는 클라이언트를 수정하고 결국 잠재적인 릴레이 공격을 방지하기 위해 EPA를 엄격하게 적용하는 단계를 수행하는 것이 좋습니다.

참고 항목

AcceptSecurityContext에 전달된 채널 바인딩은 감사 결과를 가져오기 위해 감사 전용 바인딩일 필요가 없습니다. 서비스는 EPA를 적용하는 동안 감사 모드를 실행할 수 있습니다.

클라이언트

QueryContextAttributes(TLS)를 사용하여 채널 바인딩 가져오기(고유 및 엔드포인트 채우기)
InitializeSecurityContext를 호출하고 SECBUFFER_CHANNEL_BINDINGS 채널 바인딩을 전달합니다 .

서버

클라이언트에서와 같이 QueryContextAttributes(TLS) 사용
(선택 사항) SspiSetChannelBindingFlags를 호출 하여 감사 전용으로 설정
(선택 사항) ASC의 출력 버퍼에 채널 바인딩 결과 버퍼를 추가합니다.
SECBUFFER_CHANNEL_BINDINGS 사용하여 AcceptSecurityContext 를 호출하여 EPA 수준 및 기타 구성을 지정합니다.
(선택 사항) 모서리의 경우 플래그를 사용하여 동작을 제어합니다.
- ASC_REQ_ALLOW_MISSING_BINDINGS - 오래된 타사 디바이스와 같이 아무 말도 하지 않은 클라이언트를 실패하지 마세요. SECBUFFER_CHANNEL_BINDINGS 받지 못한 인식 클라이언트는 아무것도 아닌 빈 바인딩을 보냅니다.
- ASC_REQ_PROXY_BINDINGS - TLS에서 부하 분산 장치를 종료하는 드문 경우입니다. 전달할 SECBUFFER_CHANNEL_BINDINGS 없지만 클라이언트가 TLS 채널에 요청을 넣도록 적용하려고 합니다. 이는 클라이언트가 서버 인증서가 이름과 일치하는 TLS 채널에도 배치되었는지 확인하기 위해 서비스 바인딩에 가장 유용합니다.

EPA를 적용하려면 어떻게 해야 합니까?

서비스가 EPA를 지원하면 관리자는 감사에서 전체 적용까지 EPA 상태를 제어할 수 있습니다. 이를 통해 서비스는 EPA에 대한 에코시스템의 준비 상태를 평가하고, 호환되지 않는 디바이스를 수정하고, 환경 보호를 위해 EPA를 점진적으로 적용할 수 있는 도구를 제공합니다.

다음 특성 및 값을 사용하여 사용자 환경에서 다양한 수준의 EPA를 적용할 수 있습니다.

이름	설명
None	채널 바인딩 유효성 검사가 수행되지 않습니다. 업데이트되지 않은 모든 서버의 기본 동작입니다.
허용	업데이트된 모든 클라이언트는 채널 바인딩 정보를 서버에 제공해야 합니다. 업데이트되지 않은 클라이언트는 해당 정보를 제공하지 않아도 됩니다. 애플리케이션 호환성을 허용하는 중간 옵션입니다.
필수	모든 클라이언트는 채널 바인딩 정보를 제공해야 합니다. 서버는 채널 바인딩 정보를 제공하지 않는 클라이언트의 인증 요청을 거부합니다.

이러한 특성은 감사 기능과 결합하여 다양한 수준의 EPA 적용에서 디바이스 호환성에 대한 정보를 수집할 수 있습니다. 원하는 구성을 SspiSetChannelBindingFlags에 전달합니다.

감사 - 감사 모드는 위의 EPA 적용 수준과 함께 사용할 수 있습니다.

EPA 감사 결과를 해석하려면 어떻게 해야 하나요?

감사 결과는 비트 플래그 집합입니다.

Flag	설명
SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT	클라이언트는 채널 바인딩이 가능함을 표시했습니다.
SEC_CHANNEL_BINDINGS_RESULT_ABSENT	클라이언트가 외부 채널에 바인딩을 제공하지 않았습니다.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH	클라이언트 바인딩은 서버와 다른 채널을 나타냅니다.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING	SEC_CHANNEL_BINDINGS_RESULT_ABSENT 채널 바인딩에 실패했습니다.
SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED	채널이 성공적으로 바인딩되었습니다.
SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY	클라이언트는 외부 채널에 대한 바인딩을 표시했으며 ASC_REQ_PROXY_BINDINGS 인해 전달되었습니다.
SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING	ASC_REQ_ALLOW_MISSING_BINDINGS 인해 전달된 채널 바인딩입니다.

비트 집합에 대한 정의도 있습니다.

Flag	설명
SEC_CHANNEL_BINDINGS_RESULT_VALID	모든 SEC_CHANNEL_BINDINGS_VALID_* 사례를 테스트하는 데 사용됩니다.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID	모든 SEC_CHANNEL_BINDINGS_NOTVALID_* 사례를 테스트하는 데 사용됩니다.

감사 흐름

결과를 지원하는 모든 OS는 항상 SEC_CHANNEL_BINDINGS_RESULT_VALID 및 SEC_CHANNEL_BINDINGS_RESULT_NOTVALID 하나 이상의 비트를 설정합니다.

채널 바인딩 실패: SEC_CHANNEL_BINDINGS_RESULT_NOTVALID 모든 비트를 테스트합니다. 감사 전용이 아닌 바인딩의 경우 STATUS_BAD_BINDINGS 또는 SEC_E_BAD_BINDINGS ASC 실패에 해당합니다.

SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH: 클라이언트와 서버는 모두 채널 바인딩에 대해 알고 있지만 채널에 대해 동의하지 않습니다. 이 구성이 트래픽을 검사하기 위해 HTTPS를 손상했기 때문에 공격 사례 또는 공격과 구별할 수 없는 부적절한 보안 구성입니다(예: Fiddler). 또한 클라이언트와 서버가 고유 및 엔드포인트 바인딩에 대해 동의하지 않을 수 있습니다.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING 다음 두 가지 사례로 분할됩니다.
- SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT 사용하면 클라이언트가 채널 바인딩에 대해 알고 있고 채널이 없음을 증명한다는 것을 의미합니다. 이는 TLS가 아닌 서비스의 전달 공격일 수 있지만 TLS를 수행하지만 내부 인증을 알리지 않는 클라이언트에서 실행 중인 비인식 애플리케이션일 수 있습니다.
- SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT 없으면 채널 바인딩을 수행할 수 없는 클라이언트입니다. 지원되는 모든 Windows 버전은 채널 바인딩이 가능하므로 이는 타사 또는 레지스트리 값 SuppressExtendedProtection이 설정된 시스템입니다. 이 경우 ASC_REQ_ALLOW_MISSING_BINDINGS 전달하면 SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING 됩니다.

채널 바인딩 성공: 실패에 대한 검사 역함수이거나 SEC_CHANNEL_BINDINGS_RESULT_VALID 대한 테스트입니다.

SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED 성공 사례입니다. 보안 보호가 작동합니다(또는 EPA가 감사 전용으로 사용하도록 설정된 경우 작동).
SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING ASC_REQ_ALLOW_MISSING_BINDINGS 전달되었으므로 채널 바인딩에 대한 지원을 요청하지 않은 클라이언트를 허용했습니다. 이 경우 발생하는 클라이언트는 보호되지 않으며 무엇이 잘못되었는지 확인하기 위해 조사해야 합니다. 채널 바인딩을 지원하도록 업데이트해야 하거나 중단된 애플리케이션이 업데이트되면 SuppressExtendedProtection 레지스트리 값을 지워야 합니다.
SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY 서버에 도달하는 대신 부하 분산 장치에서 TLS가 종료될 때 사용되는 플래그 ASC_REQ_PROXY_BINDINGS 관련된 특별한 경우입니다. 서버에서 클라이언트가 부하 분산 장치에서 종료된 것과 동일한 TLS 연결을 사용하고 있는지 확인할 수 없습니다. 감사를 위해 SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED 동일하게 처리됩니다.