다음을 통해 공유

무선 액세스 지점 구성 보호

게시 날짜: 2006년 8월 29일

이 페이지에서

소개
정의
문제점
해결 방법
요약

소개

이 문서에서는 중소 기업을 위한 보안 지침을 다룹니다. 다음 정보는 보다 안전하고 생산적인 컴퓨팅 환경을 구축할 수 있도록 도움을 줍니다.

요약

무선 LAN(WLAN)은 비즈니스 세계에서 논쟁이 되는 주제로, 대부분의 기업에서는 이미 특정 형태의 WLAN을 배포했거나 무선 기술의 찬반에 대한 토론에 참여하고 있습니다. 무선 네트워크를 배포한 기업은 일반적으로 자사 솔루션의 보안 문제를 걱정하는 반면 무선 기술을 도입하지 않은 기업에서는 무선 기술을 도입하지 않음으로써 생산성 향상 및 비용 절감의 기회를 놓치고 있다는 사실에 아쉬워합니다.

기술 분야의 의사 결정권자 대부분이 과거 무선 기술의 보안 문제를 우려해 왔으며 1세대 IEEE 802.11 WLAN 보안 프로토콜에서 취약점이 발견됨으로 인해 오늘날까지도 무선 기술은 안전하지 못하다는 오명에 시달리고 있습니다. 오랜 시간에 걸쳐 많은 해결 방법이 개발되었지만 무선 보안 문제를 해결하기 위해 제시되는 일반적인 솔루션은 비용 부담이 너무 크거나 자체적인 결함을 가지고 있습니다.

초기 무선 네트워크에서 발견된 취약점을 보완하려는 노력과 더불어 속도와 안정성이 향상된 기술이 개발됨에 따라 무선 전송을 보호하는 데 사용되는 표준도 그에 따라 발전했습니다. IEEE 802.11i를 기반으로 한 최신 무선 보안 프로토콜인 WPA 및 WPA2는 엄격한 보안 환경에서도 강력한 무선 트래픽 보안을 제공할 수 있습니다. 이러한 현재의 표준을 적절하게 구성하면 보다 높은 보안을 제공할 수 있으며 중소 기업 환경에서 높은 신뢰 수준을 바탕으로 사용할 수 있습니다.

개요

이 문서에 포함된 네 개의 주요 섹션에서는 중소 기업 무선 네트워크 보안을 위한 효율적인 솔루션을 디자인하고 구현하는 데 필요한 정보를 자세히 설명합니다. 이 섹션에는 다음과 같은 내용이 포함됩니다.

  • 소개. 이 섹션에서는 문서의 프레임워크에 대한 개요 및 문서 대상에 대한 정보를 비롯한 문서의 개요를 설명합니다.

  • 정의. 이 섹션에서는 문서에서 사용된 용어를 이해하는 데 유용한 몇 가지 세부 정보와 정의에 대해 설명합니다.

  • 문제점. 이 섹션에서는 중소 기업에서 무선 네트워크를 고려할 때 해결해야 하는 일반적인 문제점들과 이 문서에서 해결 방법으로 제시된 솔루션의 배경을 설명합니다.

  • 솔루션. 이 섹션에서는 안전한 무선 인프라를 계획하고, 전개하고, 배포하고, 지원하는 데 사용될 특정 단계별 지침에 대한 자세한 내용을 설명합니다. 이 솔루션 섹션은 다음과 같은 주요 하위 섹션으로 세분되어 있습니다.

    • WLAN 보안 진단. 이 섹션에서는 솔루션 계획을 전개해 나가는 데 기초가 되는 필수 정보와 사용 가능한 옵션에 대해 설명합니다.

    • 보안 WLAN 솔루션 전개. 이 섹션에서는 진단 단계에서 습득한 정보를 사용하여 계획을 결정, 작성하고 솔루션의 기초를 전개합니다.

    • 배포 및 관리. 이 섹션에서는 이 문서에 요약된 무선 네트워크 보안 솔루션을 관리하고 검증하는 데 도움이 되는 정보와 실제적인 단계별 솔루션에 대해 자세하게 설명합니다.

이 가이드를 읽어야 할 사람

이 문서는 WPA(Wi-Fi Protected Access) 또는 WPA2(Wi-Fi Protected Access 2)를 사용하여 기업의 무선 인프라를 보호하려는 중소 기업의 기술 담당 직원, 기술 구현 담당자 및 기술 관리자를 대상으로 합니다. 이 문서에서는 독자가 무선 장치, 기본 네트워킹 개념, Microsoft® Windows Server™ 2003, 인터넷 인증 서비스(IAS), Active Directory® 디렉터리 서비스 및 그룹 정책의 구성과 적용에 대한 일반적인 기술 지식을 가지고 있다고 가정합니다.

페이지 위쪽

정의

이 문서를 시작하기 전에 이 문서에서 사용되는 다음 용어 및 개념을 충분히 이해해야 합니다.

AES. AES(Advanced Encryption Standard)는 대칭적 블록 데이터 암호화 기술을 사용하며 WPA2의 일부입니다.

EAP. EAP(확장할 수 있는 인증 프로토콜)는 개발자가 RADIUS 서버와 무선 액세스 지점 간에 인증 데이터를 전달할 수 있도록 하는 802.1X 표준입니다. EAP에는 EAP MD5, EAP-TLS, EAP-TTLS, LEAP 및 PEAP를 포함하는 여러 가지 변형이 있습니다.

EAP-TLS. Microsoft에서 개발한 802.1X 표준의 EAP-TLS(EAP Transport Layer Security)는 인증에 디지털 인증서를 사용하며 오늘날 802.11i 인증의 업계 표준입니다.

IEEE 802.1X. IEEE 802.1X는 요청자(클라이언트), 인증자(무선 액세스 지점) 및 인증 서버(RADIUS) 간에 발생하는 EAP 캡슐화 프로세스를 제어합니다.

IEEE 802.11. 무선 네트워크 통신을 제어하는 IEEE 802.11 표준은 2.4GHz 대역에서 20Mbps 이상으로 트래픽을 제공하는 802.11g에서 802.11i 표준 범위에 있는 몇몇 사양을 포함하며 WPA2 암호화 및 인증을 관리합니다.

IEEE 802.11i. 802.11 표준을 개정한 IEEE 802.11i는 원래의 인증 프로세스(EAP)를 보호하기 위해 AES 블록 암호화를 사용하는 보안 방법(WPA2)을 지정하여 이전의 무선 보안 표준 및 사양의 결점을 보완합니다.

MS-CHAP v2. MS-CHAP v2(Microsoft Challenge Handshake Authentication Protocol version 2)는 MD4 및 DES 암호화를 사용하는 암호 기반, 요청-응답(challenge-response) 메커니즘의 상호 인증 프로토콜입니다. 무선 통신 보안을 위해 PEAP(PEAP-MS-CHAP v2)와 함께 사용할 수 있습니다.

PEAP. PEAP(Protected Extensible Authentication Protocol)는 TLS로 암호화되고 보호되는 보안 채널을 만들어 일반 텍스트 EAP 전송과 연관된 보안 문제를 해결하는 EAP 통신의 한 유형입니다.

SSID. SSID(서비스 집합 ID)는 WLAN에 부여되는 이름으로 클라이언트가 WLAN에 액세스하는 데 필요한 올바른 설정 및 자격 증명을 확인하는 데 사용합니다.

TKIP. TKIP(임시 키 통합 프로토콜)는 무선 네트워크를 위한 WPA 암호화 표준의 일부입니다. TKIP는 차세대 WEP로, WEP 표준에서 발견된 결함을 해결하기 위해 패킷당 키 조합 기능을 제공합니다.

WEP. WEP(Wired Equivalent Privacy)는 IEEE 802.11 표준의 일부로, 64 또는 128비트 RC4 암호화를 사용합니다. 2001년, WEP 표준에 심각한 결함이 발견되었는데 이는 대부분 RC4 키의 수동 디코딩(passive decoding)을 고려한 RC4 스트림 암호의 IV(Initialization Vector) 길이로 인한 것이었습니다.

WLAN. 무선 근거리 통신망을 말합니다.

WPA. 2003년, WEP 표준에서 발견된 취약점을 개선할 수 있도록 IEEE 802.11 표준의 상호 운용이 가능한 무선 보안 규격의 일부로 WPA(Wi-Fi Protected Access)가 발표되었습니다. 이 표준은 인증 기능을 제공하며 데이터 암호화에 TKIP를 사용합니다.

WPA2. WPA2는 2004년 9월 Wi-Fi Alliance에 의해 확립되어 완전한 IEEE 802.11i 규격의 공인된 상호 운용 가능한 버전으로, 2004년 6월에 승인을 받았습니다. 이전 버전에서와 마찬가지로 WPA2는 IEEE 802.1X/EAP 인증 또는 PSK 기술을 지원하며 나아가 AES(Advanced Encryption Standard)라는 CCMP(Counter-Mode/CBC-MAC Protocol)를 사용하는 새로운 고급 암호화 메커니즘을 구현합니다.

페이지 위쪽

문제점

많은 기업에서는 무선 기술을 도입하면 생산성과 공동 작업의 능률이 향상된다는 점을 알고 있지만 무선 네트워크로 인해 기업의 보안 환경이 취약해질 수 있다는 점을 염려하여 이 기술을 선뜻 구현하지 못하고 있습니다. 더욱 당황스러운 것은 무선 통신을 보호하는 데 사용될 수 있는 너무나 다양한 방법이 제시되고 있다는 것과 이러한 방법들의 효율성에 대한 엇갈린 보고서가 발표되고 있다는 점입니다.

무선 기술은 배포의 보안과 관련해서는 물론 배포 여부 자체에 대한 문제에 이르기까지 다양한 문제점을 중소 기업에 제기합니다. 다음은 이 문서에서 설명하게 될 무선 네트워킹에 관련한 일반적인 논제입니다.

  • WLAN 구현 여부에 대한 결정

  • 무선 위험 및 완화에 대한 이해

  • WLAN 환경 보호 방법 결정

  • 올바른 WLAN 보안 옵션 선택

  • 무선 네트워크 구현의 보안 수준 검증

  • 기존 자산을 무선 보안 솔루션에 통합

  • 악의적인 무선 장치 연결 탐지 및 방지

페이지 위쪽

해결 방법

이 섹션에서는 중소 기업 환경에 배포할 수 있는 안전한 무선 솔루션에 대한 디자인, 개발, 구현 및 지원에 대해 설명합니다. 앞에서 언급한 것처럼 무선 기술을 사용하는 과정에는 여러 가지 문제점이 따릅니다. 여기서는 무선 네트워킹의 이점을 최대한 효율적이고 안전하게 활용할 수 있도록 이러한 문제점에 대한 해결 방법을 설명합니다.

WLAN 보안 진단

오늘날의 무선 기술은 중소 기업 환경에 배포할 수 있을 정도로 빠르고 안전한 단계까지 발전했지만 여전히 고려해야 할 여러 가지 요인이 있으며 무선 네트워크를 보호하는 데 사용할 수 있는 방법도 그만큼 다양합니다. 이 섹션에서는 무선 네트워크를 보호하는 데 사용할 수 있는 여러 가지 일반적인 방법을 설명하며, 특정 환경에 맞는 최적의 솔루션을 결정할 수 있도록 안내하고, 각 접근 방법에 대한 찬반 의견을 소개합니다.

무선 네트워킹의 이점

WLAN 기술을 구현하여 얻을 수 있는 이점은 업무상의 이점과 운영상의 이점으로 나눌 수 있습니다. 운영상의 이점으로는 관리 비용 및 자본 지출의 절감을 들 수 있으며 업무상의 이점으로는 생산성 향상, 보다 효율적인 업무 처리, 새로운 업무 기능 창출의 가능성 증대 등을 들 수 있습니다.

업무상의 이점

WLAN 기술을 사용함으로써 파생되는 핵심적인 업무상 이점은 대부분 직원의 유연성 및 이동성이 증가하는 데에서 얻을 수 있습니다. 무선 네트워크를 사용하면 더 이상 인력이 사무실의 한 곳에 묶여 있을 필요가 없으며 비교적 손쉽게 사무실을 이동할 수 있습니다. 이러한 유연성과 이동성은 다음과 같은 이점을 창출합니다.

  • 기업 내의 영업부 직원과 같이 이동이 잦은 인력의 경우에는 손쉽게 사무실 간을 이동하거나 현장을 오고 갈 수 있으며 기업 네트워크에 투명하게 연결할 수 있습니다. 네트워크 포트나 얽혀 있는 케이블을 찾아 헤매지 않고도 거의 즉시 연결할 수 있기 때문에 엄청난 시간을 절약할 수 있으며 케이블로 연결된 네트워크에서 발생하는 복잡한 문제를 피할 수 있습니다.

  • 기술 담당 직원이 회사의 건물 내에 상주하지 않아도(또는 회의 중이거나 자신의 자리를 비운 경우에도) 자신들이 관리하는 시스템에 항상 연결된 상태를 유지할 수 있습니다. 기업의 IT 직원은 랩톱, Tablet PC 또는 핸드헬드 컴퓨터와 같은 휴대용 기기를 사용하여 모든 요구에 즉각적으로 응답할 수 있습니다.

  • 모든 사람이 정보에 쉽게 액세스할 수 있습니다. 누군가가 자신의 자리에 있는 보고서의 사본을 만들거나 보고서를 검색해야 할 때 회의를 지연하지 않아도 됩니다. 회의실 단상의 흐릿한 화면이 아닌 각자의 컴퓨터에서 프레젠테이션을 공유할 수 있으며 회의 시 원격지 사무실 직원 및 텔레커뮤터와 공동 작업을 수행할 수 있도록 대화형 기술을 사용할 수 있습니다.

  • 구조적 변화를 빠르고 쉽게 구현할 수 있기 때문에 조직의 유연성이 크게 향상됩니다. 예를 들어, 네트워크 케이블 작업이 더 이상 필요하지 않으므로 사무실을 전적으로 개편할 수도 있습니다.

  • 무선 기술은 비즈니스 환경에 완전히 새로운 범위의 기술 응용 및 솔루션을 가능하게 해줍니다. PDA(개인용 정보 단말기) 및 Tablet PC와 같은 장치는 네트워크 환경에 완벽하게 통합될 수 있습니다. 예전에는 IT의 혜택을 받지 못했던 직원 또는 비즈니스 기능이 네트워크 연결을 통해 윤택해질 수 있습니다. 예를 들어, 간이 식당, 모임 장소, 병실, 상가, 식당 및 생산 현장에서도 기술 솔루션에 쉽게 액세스하여 생산성 향상을 꾀할 수 있습니다.

운영상의 이점

무선 기술을 통해 얻게 되는 운영상의 이점 또한 다양하며 이는 비즈니스 유형 및 사용 중인 설비에 따라 다를 수 있습니다. 운영상의 이점은 다음과 같습니다.

  • 케이블 네트워크 인프라에 대한 의존도가 줄어들기 때문에 네트워크 구축 비용이 대폭 감소합니다. 네트워크 연결을 구성할 수 없는 장소(옥외 공간 또는 분산형 사무 공간)에도 WLAN 기술을 통해 저렴한 비용으로 액세스할 수 있습니다.

  • 가변적인 요구 수준에 맞춰 보다 효율적이고 적절한 방식으로 네트워크를 확장할 수 있습니다. 이는 네트워크 포트의 수를 늘리는 것보다 무선 액세스 지점을 서로 다른 위치에 배포하거나 이동하는 편이 정체를 해결하기가 훨씬 쉽기 때문입니다.

  • 무선 네트워크 장비는 네트워크 케이블 인프라와 같은 영구 설비가 아니기 때문에 설비 인프라에 들어가는 고정 자본을 줄일 수 있습니다. 따라서 조직을 확장하거나 사무실의 위치를 변경해야 하는 경우에도 유연성이 높아질 수 있습니다. 또한 고속 무선(802.11a/g/n)은 이전의 저속 이더넷 또는 토큰 링을 대체할 수 있는 경제적인 대안입니다.

무선 네트워킹의 취약점

무선 네트워크에 사용할 수 있는 다양한 보안 솔루션에서 제시하는 보안 수준을 이해하려면 무선 네트워크 사용 시 직면할 수 있는 일반적인 위협을 이해해야 합니다. 기존 네트워크에서 해결해야 하는 취약점 및 공격 유형은 잘 알려져 있지만 무선 네트워크의 취약점은 이러한 일반적인 위험과는 사뭇 다릅니다.

표 1. 일반적인 WLAN 보안 위협

위협 설명
도청을 통한 데이터 노출 누군가가 안전하지 못한 무선 트래픽에 대해 도청 공격을 시도하면 기밀 데이터가 노출되거나 사용자 자격 증명이 검색되거나 ID 도난이 발생할 수 있습니다. 심지어 도청을 통해 수집한 정보를 사용하여 취약하지 않은 시스템에도 공격을 감행할 수 있습니다.
데이터 가로채기 및 수정 네트워크 리소스에 액세스할 수 있는 침입자는 악의적인 시스템을 네트워크에 포함시켜 적법한 두 시스템 사이에서 전송 중인 데이터를 가로채거나 수정할 수 있습니다.
스푸핑 내부 네트워크에 액세스할 수 있는 침입자는 데이터를 위조하여 이 데이터가 적법한 트래픽인 것처럼 위장할 수 있습니다. 한 예로, 외부의 통신보다 내부 사용자들이 더 쉽게 신뢰할 수 있는 스푸핑 전자 메일 메시지는 사회 공학 공격이나 트로이 목마 공격이 발생할 가능성을 높여 줍니다.
서비스 거부(DoS) 어떤 보안 솔루션을 구현하든, WLAN은 의도적이거나 우발적인 DoS 공격에 노출되어 있습니다. 이러한 방해 공격은 전자 렌지와 같이 간단한 가전 제품이나 네트워크를 무분별한 트래픽으로 채우는 장치 세트를 통해 발생할 수 있습니다.
무료 로딩
(리소스 도용)		 침입자가 사용자의 네트워크를 무료 인터넷 액세스 지점으로 사용하려는 것 외에 다른 나쁜 의도를 가지고 있지 않은 경우도 있습니다. 무료 로딩은 네트워크에 직접적으로 해를 끼치지는 않지만 합법적 사용자가 이용하는 네트워크 연결 속도를 떨어뜨리거나 악성 프로그램 위협이 침투할 수 있는 관리되지 않는 경로를 열어 줄 수 있습니다.
우발적인 위협 및 관리되지 않는 연결 보안되지 않은 WLAN 환경에서는 방문객이 무선 네트워킹이 가능한 장치를 시작하기만 하면 내부 네트워크에 액세스할 수 있습니다. 이러한 관리되지 않는 장치는 이미 바이러스에 감염되었거나 네트워크 칩임자에게 취약한 공격 지점을 제공할 수 있습니다.
악의적인 WLAN 액세스 지점 무선 네트워크를 구축하지 않은 기업이라도 관리되지 않는 무선 네트워크의 보안 위협으로부터 자유롭지는 않습니다. 무선 하드웨어는 비교적 가격이 저렴하기 때문에 일부 직원이 관리 및 보호되지 않는 네트워크를 기업 환경 내에 구축할 수 있습니다.
오늘날과 같이 보안이 중요시되는 환경에서는 무선 데이터 전송과 관련된 이러한 많은 보안 위험이 매우 잘 알려져 있지만 1세대 무선 보안 기술이 확립되던 당시에는 그다지 잘 드러나지 않았습니다. 무선 데이터 브로드캐스트를 보호하기 위해 WEP가 만들어졌을 때는 어느 정도의 보안이 보장되는 유선 데이터 전송과 비교하여 본질적인 보안상의 결함을 보상해 줄 수 있는 대책에 대한 요구가 많지 않았습니다. 그 이유는 너무나 새로운 기술이었기 때문에 극소수의 사람만이 네트워크에서 발생할 수 있는 그러한 위협을 인지했기 때문입니다. 침입자가 사용하는 방법이 진화하면서 무선 데이터 전송이 잠재적인 적대 환경을 통과한다는 사실과 케이블 LAN 통신에 준하는 보안이 필요하다는 사실이 명백해졌습니다. WEP 보안의 결함이 널리 공표되기 시작하면서 네트워크 보안 환경도 빠르게 변화해 갔습니다. 네트워크 검색자(War-Driver)들의 이야기가 주요 매체에 눈에 띄게 등장하고 정부에서는 데이터 및 ID 보호에 대한 법안을 마련하기 시작했습니다. 상황이 이렇게 전개되면서, 많은 기업에서는 무선 기술의 실행 가능성과 안정성을 의심하여 이를 포기하거나 WEP 표준의 본질적인 결함을 해결하기 위해 복잡한 방법들을 개발했습니다. 이러한 복잡한 솔루션 중 일부는 오늘날까지도 사용 및 판매되고 있습니다. 그러나 다음 섹션에서는 이러한 위협으로부터 무선 네트워크를 보호하기 위해 더 이상 이처럼 복잡한 솔루션을 사용할 필요가 없으며 보안 전망에 발맞추어 무선 기술도 발달했기 때문에 이에 대한 재평가가 필요하다는 점을 분명하게 설명하고 있습니다. ##### 올바른 WLAN 보안 솔루션 선택 1세대 WLAN 기술의 결함이 밝혀진 이후 무선의 취약점을 개선하기 위한 엄청난 노력이 전개되었습니다. Microsoft를 비롯한 기타 무선 관련 공급업체에서는 무선 표준을 개선하는 데 초점을 맞추었으며 많은 분석가, 네트워크 보안 공급업체 등에서도 이전 무선 표준의 약점을 해결할 수 있는 방안을 마련하기 위해 노력했습니다. 이러한 노력의 결과로, 무선 보안 문제를 처리할 수 있는 다양한 접근 방법이 소개되었습니다. 다음 표에서는 WLAN 기술을 구현하지 않도록 결정하는 가장 일반적인 접근 방법을 제외한 몇 가지 주요 대안을 비교 설명합니다. **표 2. WLAN 보안 접근 방법 비교**

기능 WPA 및 WPA2 정적 WEP VPN IPsec
강력한 인증 (참고 참조) 예 아니요 예(공유 키 인증을
사용하지 않는 경우에만)		 예(인증서 또는 Kerberos 인증을 사용하는 경우)
강력한 데이터 암호화 예 아니요 예 예
투명한 연결 및 재연결 예 예 아니요 예
사용자 인증 (참고 참조) 예 아니요 예 아니요
컴퓨터 인증 (참고 참조) 예 예 아니요 예
브로드캐스트 및 멀티캐스트 트래픽 보호 예 예 예 아니요
추가 네트워크 장치 예, RADIUS 서버 아니요 예, VPN 및 RADIUS 서버 아니요
패킷을 포함한 WLAN에 대한 액세스 보호 예 예 아니요 아니요
**참고**   강력한 인증에 대해 부연 설명하면 IPsec 터널 모드를 사용하는 많은 VPN 구현이 XAuth라는 취약한 공유 키 인증 기법을 사용합니다. 현재 버전의 Windows 운영 체제는 IPsec 연관 사용자 인증을 지원하지 않지만 Windows Vista 및 Longhorn에서는 이 기능을 사용할 수 있습니다. 컴퓨터 인증은 컴퓨터에 로그온한 사용자가 없는 경우에도 컴퓨터가 WLAN 및 LAN에 연결되어 있는 것을 뜻합니다. 로밍 프로필과 같은 일부 도메인 기반 기능이 올바로 작동하려면 이 기능이 필요합니다. 표의 설명과 같이, 무선 네트워크를 보호하는 데 사용할 수 있는 다양한 옵션을 검토할 때에는 여러 가지 요인을 고려해야 합니다. 그러한 평가에는 구현 및 관리와 관련된 비용에서부터 해당 솔루션의 일반적인 보안 사항에 이르는 모든 내용이 포함됩니다. 또한 접근 방법별로 장단점이 있기 때문에 현명한 의사 결정을 내리기 위해서는 각 솔루션을 자세히 검토해야 합니다. WLAN 구현을 보호하는 데 사용할 수 있는 옵션을 보다 손쉽게 이해할 수 있도록 다음 항목에서는 각 접근 방법에 대해 자세히 설명하고 있습니다. 각 항목은 제공하는 보안의 수준에 따라 순서대로 나열되어 있습니다. - WLAN 기술을 배포하지 않음 - EAP-TLS와 함께 WPA 사용 - PEAP-MS-CHAP v2와 함께 WPA 사용 - PEAP-MS-CHAP v2 및 인증서 서비스와 함께 WPA 사용 - VPN 사용 - IPsec 사용 - WEP 사용 - WLAN 보안 없음 ###### WLAN 기술을 배포하지 않음 보안 전문가들 사이에서는 "가장 안전한 시스템은 가동되지 않는 시스템"이라는 격언이 있습니다. 따라서 무선 네트워킹을 포함한 모든 기술을 가장 안전하게 배포하는 방법은 배포하지 않는 것입니다. 물론 이 접근 방법을 사용하는 기업은 어떤 기술도 사용하지 않는 기업일 것이므로 오늘날과 같이 기술 의존도가 높은 비즈니스 환경에서는 경쟁력을 가질 수 없습니다. 이전에 언급한 것과 같이 모든 기업에서는 자신들의 요구, 위험에 대한 허용 수준 및 채택을 고려 중인 모든 기술에 수반되는 위험의 정도를 진단해야 하는데, 무선 기술도 이와 마찬가지입니다. 무선 네트워크는 많은 이점을 제공하지만 특정 기업의 경우에는 이러한 이점이 제대로 발휘될 수 없거나 적용조차 되지 않을 수 있습니다. 어떤 무선 보안 솔루션이 가장 기업에 적합할지를 진단할 때에는 무선 솔루션을 아예 배포하지 않는 옵션을 포함하여 모든 옵션을 고려하십시오. 그러나 기업에서 WLAN을 배포하지 않기로 결정했다면 이 결정을 적극적인 회사 정책의 일부로 추진하여 악의적인 WLAN이 최종 사용자에 의해 배포되어 네트워크 보안을 손상시키지 않도록 해야 합니다. ###### EAP-TLS와 함께 WPA 사용 현재 버전의 Windows 기반 무선 클라이언트가 지원하는 가장 강력한 802.1X 인증 방법은 사용자 및 컴퓨터 인증서 모두를 사용하는 EAP-TLS(Extensible Authentication Protocol Transport Layer Security)와 함께 WPA 또는 WPA2를 사용하는 것입니다. EAP-TLS는 디지털 인증서를 사용하여 상호 인증을 제공합니다. 상호 인증이란 무선 클라이언트와 인증 서버가 서로 간에 인증을 수행하는 형식을 말합니다. EAP-TLS 인증에는 인증서를 발행하고 해당 인증서를 최신으로 유지하기 위한 PKI(공개 키 인프라)가 필요합니다. 최고 수준의 보안을 위해서는 무선 액세스를 위한 사용자 및 컴퓨터 인증서를 모두 발행하도록 PKI를 구성해야 합니다. PKI와 관련된 구현 비용과 관리 오버헤드 때문에 이 보안 솔루션은 한정된 중소 기업 또는 대기업에서만 사용되었지만 EAP-TLS를 구현하는 데 필요한 기본적인 인증서 서비스를 제공하는 Microsoft Small Business Server가 출시됨에 따라 이제 소규모 환경에서도 PKI를 사용할 수 있게 되었습니다. **참고**   현재는 WPA2를 대규모 환경에서 효과적으로 구현하는 데 영향을 줄 수 있는 그룹 정책 개체(GPO)가 지원되지 않습니다. 그러나 WPA2의 GPO 지원을 추가하기 위한 업데이트가 Windows Server 2003 및 Windows XP용으로 개발 중입니다. 차세대 Windows인 Vista 및 Longhorn에서는 WPA2 표준을 기본적으로 지원하게 될 것입니다. ###### PEAP-MS-CHAP v2와 함께 WPA 사용 현재 버전의 Windows 기반 클라이언트에서 지원하는 두 번째로 강력한 보안 구현은 강력한 암호 요구 사항을 가진 MS-CHAP v2(Microsoft Challenge Handshake Authentication Protocol version 2) 및 PEAP(보호된 EAP)와 함께 WPA 또는 WPA2를 사용하는 것입니다. PEAP-MS-CHAP v2는 PKI를 배포할 수 없는 경우 신뢰할 수 있는 무선 네트워크 배포를 위한 실용적이고 안전한 옵션으로 사용할 수 있습니다. PEAP는 TLS를 사용하는 단방향 인증 방식으로, 인증 서버로부터 암호화된 채널을 만들고 클라이언트는 그 채널을 통해 다른 프로토콜을 사용하여 스스로를 인증합니다. 원래 전화 접속 및 VPN 원격 액세스를 위해 디자인된 MS-CHAP v2는 무선 클라이언트에 대한 강력한 암호 기반 인증을 지원합니다. 그러나 네트워크에서 강력한 사용자 암호 정책을 시행하는 경우에만 사용할 수 있습니다. ###### PEAP-MS-CHAP v2 및 인증서 서비스와 함께 WPA 사용 자사 솔루션에 인증서 서비스 및 암호 기반 PEAP-MS-CHAP v2 솔루션의 두 가지 접근 방법 요소를 모두 포함시키려는 기업에서는 이 두 가지를 결합하여 사용할 수 있습니다. 그러나 이 문서를 작성하는 현재 시점에서, 안전한 EAP-TLS 솔루션이 가동되고 있는 네트워크에 PEAP-MS-CHAP v2를 추가한다고 해서 부가적인 보안 이점을 얻지는 못합니다. 사실상, EAP-TLS와 함께 PEAP-MS-CAHP v2를 사용하면 두 개의 TLS 채널(하나의 채널이 나머지 채널의 내부에 들어 있는 구조)이 만들어지기 때문에 인증 처리 속도가 늦어집니다. 따라서 이러한 이중 암호화는 별다른 소용이 없습니다. ###### VPN 사용 WEP 보안의 결함이 처음 발견되었을 때 많은 보안 전문가들과 업계 지도자들은 VPN을 사용하여 무선 네트워크를 보호할 것을 제안했습니다. VPN 기술은 인터넷과 같은 적대적인 네트워크를 통과하는 네트워크 통신을 보호하는 안전성이 입증된 방법이며 WEP 결함을 해결하는 솔루션으로 여전히 많은 환경에서 사용되고 있습니다. 보안 측면에서 볼 때는 많은 장점이 있지만 무선 위협을 해결하기 위해 특별히 디자인된 WPA 솔루션이 제공하는 유연성과 비교해 볼 때는 그다지 매력적이지 못한 몇 가지 결함이 있습니다. 무선 네트워크를 보호하기 위해 VPN 기술과 조합하여 WPA 솔루션을 구현할 수 있지만 그러한 솔루션은 순수한 WPA 기반 솔루션을 뛰어넘는 이점을 제공하지 못합니다. 특히 VPN 솔루션을 조합할 때 복잡한 계층을 무선 네트워크에 추가로 구축해야 하는 경우는 더욱 그러합니다. 유용성은 VPN을 WLAN 보안 솔루션의 일부로 추가하려는 경우 고려해야 할 또 다른 문제입니다. VPN 사용 시 인터넷을 통해 비즈니스 네트워크에 연결하려는 사용자는 VPN과 연관된 추가적인 인증 요건 및 시간 제한을 염두에 두고 있지만 그러한 추가적인 단계는 LAN을 통해 리소스에 쉽게 연결해왔던 사용자에게는 부담스럽게 느껴질 수 있습니다. 일부 기업에서는 이미 원격 사용자를 위해 VPN 솔루션을 구축했기 때문에 이 솔루션을 사용하려고 할 수 있으며 이 솔루션 비용을 정당화하기 위해 해당 시스템의 사용률을 더욱 높이려 할 수 있습니다. 이런 경우라면 이 방법을 선택하기 전에 다음과 같은 추가적인 문제를 고려해 보아야 합니다. - 터널을 통한 통신이 허용되려면 먼저 VPN 연결이 설정되어야 하기 때문에 사용자가 로컬 컴퓨터에 로그온한 후 VPN에 연결하면 컴퓨터 그룹 정책이 적용되지 않습니다. (사용자가 컴퓨터에 로그온할 때 **전화 접속 네트워킹으로 로그온**을 선택하면 먼저 VPN 연결이 완료되고 그룹 정책이 적용됩니다.) - 대부분의 VPN 서버는 전화 접속 또는 광대역 트래픽과 같은 저속 연결을 보호하기 위해 디자인되었기 때문에 여러 고속 연결이 설정되면 네트워크 병목이 발생할 수 있습니다. - VPN 구성에 따라 무선 액세스 지점 간을 로밍할 때에도 사용자에게 문제가 발생할 수 있습니다. VPN 연결은 아주 잠깐 동안 연결이 끊어져도 종료되는 경우가 허다하며 이 경우 사용자는 한 액세스 지점에서 다른 액세스 지점으로 이동할 때마다 수동으로 인증해야 합니다. 사용자의 컴퓨터가 대기 모드 상태로 들어간 경우에도 같은 동작이 발생할 수 있습니다. ###### IPsec 사용 WLAN의 보안을 위한 VPN과 같이 WEP에서도 발견된 결함을 극복해야 할 필요성이 대두되면서 무선 네트워크 보안을 위해 IPsec을 사용하게 되었습니다. 물론 IPsec은 특정 종류의 여러 네트워크 트래픽을 보호하기 위한 신뢰할 만한 수단이며 WLAN에서 사용할 때에는 무엇보다 투명성 측면에서 우수합니다. IPsec은 WLAN 하드웨어에 영향을 받지 않으며 추가 서버 또는 소프트웨어가 필요하지 않기 때문에 오버헤드도 낮습니다. 그러나 무선 네트워크 보안에 IPsec을 사용할 때에는 몇 가지 문제점이 있습니다. 다음은 그 중 일부입니다. - IPsec은 서로를 인증하고 키를 교환하는 두 당사자 간의 통신에 관여하기 때문에 브로드캐스트 또는 멀티캐스트 트래픽을 보호할 수 없습니다. - IPsec은 무선 네트워크 자체가 아닌 네트워크 패킷만 보호합니다. - IPsec은 사용자에게는 투명하지만 MAC 계층이 아닌 네트워크 계층에서 작동하기 때문에 네트워크 장치에 대해서는 완전한 투명성을 확보하지 못합니다. 이러한 이유로 방화벽 규칙에 대한 요구 사항이 추가되기도 합니다. - IPsec을 사용할 수 없는 모든 장치는 WLAN 트래픽을 모니터링할 수 있는 침입자의 탐색 또는 공격에 취약하게 됩니다. - IPsec을 무선 네트워크 트래픽 보호 외에 기타 응용 프로그램을 위한 종단 간 보호를 제공하는 데 사용하는 경우에는 대규모 환경에서의 IPsec 정책 관리가 복잡한 문제로 떠오를 수 있습니다. ###### WEP 사용 정적 WEP는 가장 기본적인 형태의 802.11 기반 보안으로, 공유 키를 사용하여 액세스를 제어하고 해당 키를 무선 트래픽을 암호화하는 기반으로 사용합니다. 이 접근 방법의 가장 매력적인 부분은 간단하다는 점입니다. 정적 WEP는 보호되지 않는 무선 설정의 보안 수준을 약간 높여 주기는 하지만 몇 가지 심각한 관리 및 보안 결함이 있습니다. 예를 들어, WEP WLAN은 어느 곳에서든 적게는 몇 분, 많게는 몇 시간 내에 공유 키 및 SSID(브로드캐스트되지 않은 경우)를 검색할 수 있기 때문에 일반적인 랩톱과 인터넷에서 바로 구할 수 있는 간단한 도구를 사용하여 네트워크에 액세스할 수 있습니다. 정적 WEP의 성능을 개선하는 한 가지 방법은 MAC 필터링을 사용하여 미리 지정한 클라이언트 그룹만 네트워크에 액세스할 수 있도록 액세스 지점을 구성하는 것입니다. 그러나 이러한 접근 방법도 WLAN에 연결된 컴퓨터의 MAC 주소를 검색하여 스푸핑하는 도구에 의해 쉽게 공격을 받을 수 있습니다. WPA 또는 WPA2를 지원하지 않는 환경인 경우 WEP와 함께 다른 보안 기술을 조합하여 보안 수준을 약간 높일 수는 있지만 이러한 구성도 보안되지 않는 WLAN 구현에서 안전한 WPA 기반 구성으로 전환하는 단계에서만 사용하는 것이 좋습니다. 이러한 방법을 가장 안전한 것부터 나열하면 다음과 같습니다. - 사용자 및 컴퓨터 인증서 모두를 사용하는 EAP-TSL과 함께 WEP 802.1X 인증을 사용하고 정기적으로 재인증을 수행 - 강력한 사용자 암호 정책을 시행하는 PEAP-MS-CHAP v2와 함께 WEP 802.1X 인증을 사용하고 정기적으로 재인증을 수행 ###### WLAN 보안 없음 어떤 중소 기업 환경에서도 보안되지 않는 무선 네트워크를 구현하는 것을 권장할 수는 없지만 경우에 따라 보안되지 않는 무선 네트워크 구성이 더 나은 솔루션이 될 수 있는 상황도 존재합니다. 예를 들어, 많은 도시 및 지자체에서는 자유로운 무선 액세스 영역을 고려하거나 구현하고 있는데, 이러한 상황에서는 인터넷에 대한 직접적인 연결만 제공하는 보안되지 않는 무선 액세스 지점으로 구성된 네트워크를 사용하는 것이 더 효과적일 수 있습니다. 그러나 그 의도나 목적이 무엇이든 간에 보안되지 않는 무선 네트워크는 수많은 공격에 무방비 상태로 노출되어 있다는 사실을 이해해야 합니다. ##### WPA 또는 WPA2 WPA(Wi-Fi Protected Access) 및 WPA2(Wi-Fi Protected Access 2) 프로토콜은 모두 IEEE 802.11 기반 무선 네트워크에 대한 위협에 대처하기 위해 디자인되었습니다. 그러나 이 두 프로토콜은 몇 가지 차이점이 있습니다. WPA는 WEP 표준에서 발견된 보안적 결함에 대한 대안으로 2003년 개발되었으며 데이터 암호화에 TKIP를 사용하는 상호 인증을 구현하고 스푸핑 및 되풀이(replay) 공격을 무력화하기 위한 서명된 메시지 무결성 검사를 통합하여 이러한 결함을 효과적으로 해결했습니다. WPA2는 TKIP 대신 AES를 사용하여 네트워크 트래픽 보안을 향상시킴으로써 WPA 표준보다 더 주목을 받고 있습니다. WPA와 WPA2는 WEP보다 월등한 보안 성능을 제공하며 적절한 보호가 제공되는 상황에서는 현재 이 두 프로토콜에 대해 어떠한 보안적 결함도 알려져 있지 않습니다. 그러나 WPA2가 WPA보다 안전한 것으로 널리 인식되고 있기 때문에 인프라에서 WPA2 프로토콜을 지원할 수 있고 추가적인 관리 오버헤드를 줄일 수 있다면 가능한 한 WPA2를 사용하는 것이 좋습니다. 오늘날 만들어지는 대부분의 무선 액세스 장치는 WPA2 공인 장치이며 최신 버전의 Windows, 특히 서비스 팩 2(SP2)가 설치된 Windows XP 및 SP1이 설치된 Windows Server 2003의 경우에도 WPA2를 공식적으로 지원합니다. WPA2를 지원하는 무선 장치 및 클라이언트는 WPA2를 지원하지 않는 환경에 일부 무선 액세스 지점 또는 클라이언트가 현재 배포되어 있는 경우 이전 WPA 표준도 사용할 수 있습니다. **참고**   Windows XP SP2 기반 클라이언트에서 WPA2 인증을 사용하려면 추가 업데이트 패키지인 [WPA2(Wi-Fi Protected Access 2)/WPS IE(Wireless Provisioning Services Information Element) 업데이트](https://support.microsoft.com/default.aspx?scid=kb;ko-kr;893357)가 필요합니다. 이 업데이트에 대한 자세한 내용은 https://support.microsoft.com/default.aspx?scid=kb;ko-kr;893357을 참조하십시오. 또한 현재 버전의 Windows에서는 WPA2를 위한 GPO를 지원하지 않기 때문에 이러한 점이 WPA2 구현을 WPA보다 복잡하게 만드는 관리상의 단점이 될 수 있으며, WPA와 WPA2는 모두 비교적 안전하기 때문에 이러한 내용이 WPA 또는 WPA2 중 하나를 결정하는 데 결정적인 요인으로 작용할 수 있습니다. #### 보안 WLAN 솔루션 전개 이전 섹션에서는 사용을 고려할 수 있는 서로 다른 WLAN 보안 옵션에 대한 배경 정보와 함께 무선 네트워크에서 발생할 수 있는 일반적인 위협과 각각의 접근 방법이 그러한 위협에 어떠한 방식으로 대처할 수 있는지 또는 어떤 부분이 취약한지에 대해 살펴 보았습니다. 앞에서 설명된 정보를 바탕으로, 이제는 특정 비즈니스 환경에 어떤 옵션을 각각 적용할 수 있는지에 대한 현명한 의사 결정을 내릴 수 있을 것입니다. 최근 WPA 및 WPA2 구현을 통해 무선 네트워크 표준에 대한 보안 수준이 향상되면서 WEP의 심각한 결함이 해결되었으며 이로써 무선 연결을 보호하기 위한 IPsec 또는 VPN과 같은 해결 방법에 대한 필요성도 축소되었습니다. 정적 또는 동적 WEP 옵션은 어떤 형태로도 권장되지 않으며 비보안 기능이 유용한 경우는 극히 한정된 환경에만 국한됩니다. 이러한 전제를 감안하면 WLAN 구현을 위한 포괄적이고 효율적인 보안 솔루션을 구성하려는 경우에 고려할 수 있는 옵션은 몇 가지에 불과합니다. 다음 섹션에서는 의사 결정권자들이 무선 네트워크를 보호하기 위해 살펴볼 수 있는 나머지 접근 방법을 소개합니다. Microsoft에서 권장하는 이러한 솔루션은 업계 분석가, 보안 전문가 및 선도적인 공급업체들로부터 안전하고 효율적인 무선 네트워크를 구현할 수 있는 가장 안전한 방법으로 널리 인정받는 것들입니다. 이 문서에서는 중소 기업 환경에 가장 적합한 방법에 중점을 두고 설명하고 있지만 모든 옵션을 고려하여 보다 현명한 의사 결정이 이루어질 수 있도록 전반적인 내용을 살펴보는 것이 좋습니다. ##### Microsoft 보안 WLAN 의사 결정 프로세스 Microsoft에서는 두 가지 WLAN 보안 프로세스와 하나의 혼합된 접근 방법을 선택하도록 권장합니다. 두 가지의 주요 솔루션을 보안 수준에 따라 정렬하면 다음과 같습니다. - 인증서 서비스를 사용하여 EAP-TLS와 함께 WPA2 사용 - PEAP-MS-CHAPv2와 함께 WPA2 사용 각 솔루션에서 제공하는 보안 수준은 차치하고, 이 두 가지 접근 방법 간의 결정 요인은 각 솔루션을 구현하고 지원하는 데 필요한 리소스로 압축됩니다. PEAP-MS-CHAPv2와 함께 WPA 또는 WPA2를 사용하는 경우에는 기본적으로 인증서 인프라가 필요하지 않기 때문에 기술적 전문 지식이나 설비 요구 사항이 비교적 적습니다. 현재 출시된 모든 장치가 WPA2를 공식 지원하고 가격도 비싸지 않기 때문에 WPA가 가진 관리적인 이점이 WPA2보다 비교 우위에 있어 WPA를 선택한 경우라고 하더라도 WPA2를 지원하는 장치를 사용하는 것은 적절한 선택이 될 수 있습니다. 또한 WPA2 AES 암호화 방법은 WPA의 TKIP보다 안전한 것으로 널리 알려져 있고 이후 릴리스에서는 WPA2에 대한 GPO 지원이 가능하기 때문에 미래의 WPA2 구현을 위한 발판을 마련하는 것이 좋습니다. EAP-TLS와 함께 WPA 또는 WPA2를 사용하는 방법이 WLAN 보안을 위한 가장 안전한 옵션이기는 하지만 이 방법을 사용하려면 인증서 인프라가 필요하기 때문에 구현 및 관리 비용이 많이 듭니다. 그러나 많은 중소 기업에서 이미 EAP-TLS와 함께 WPA2를 사용하는 데 필요한 시스템 요건을 갖추고 있기 때문에 이 방법은 실제로 보다 매력적인 옵션이 될 수 있습니다. 필요한 기술을 갖추지 못한 경우라도 많은 기업에서 이 솔루션이 의존하는 동일한 기술에 대한 다른 요구(인증서 및 RADIUS)를 가지고 있기 때문에 이 솔루션을 구현할 만한 비즈니스적 또는 기술적 이유가 있다고 할 수 있습니다. [![](images/Cc875845.SWCG1(ko-kr,TechNet.10).gif)](https://technet.microsoft.com/ko-kr/cc875845.swcg1_big(ko-kr,technet.10).gif) **그림 1. Microsoft WLAN 의사 결정 트리** 그림 1의 순서도는 이전 가이드에서 기업이 자신들의 환경에 가장 잘 맞는 보안 WLAN 접근 방법을 결정하는 데 도움을 주도록 사용되었습니다. 또한 이 순서도는 대기업의 정의에 대한 가정을 할 수 있도록 합니다. 이 순서도에서 대기업은 500명 이상의 직원과 최소 5명의 기술 관련 종사자로 구성된 IT 지원 부서를 갖춘 기업체를 의미합니다. 앞에서 설명한 바와 같이 이 의사 결정 트리는 다소 오해의 소지가 있습니다. 왜냐하면 많은 중소 기업에서 이미 인증서 서비스를 사용한 WPA2 EAP-TSL을 구현할 수 있는 리소스와 능력을 갖추고 있으며 최소 5명의 IT 기술자를 보유하고 있을 뿐만 아니라 기본적인 EAP-TLS 구현(4개의 추가 서버, 그 중 하나는 네트워크에 연결되지 않은 상태로 유지)을 위한 추가적인 인프라 요건을 지원할 수 있기 때문입니다. 이러한 사실을 감안할 때 대부분의 중소 기업을 위한 최적의 솔루션은 인증서 서비스를 사용하여 EAP-TLS와 함께 WPA2를 사용하는 접근 방법일 수 있습니다. 따라서 이 문서에서는 이 접근 방법에 대해 중점적으로 다룹니다. 그러나 항상 예외는 있기 때문에 조직에서 다른 접근 방법을 원하는 경우 다양한 가이드를 참고하여 이러한 요구를 충족할 수 있습니다. 예를 들어, PEAP-MS-CHAP v2와 함께 WPA를 사용하는 접근 방법을 선호한다면 [PEAP 및 암호를 사용하여 무선 LAN 보안](https://www.microsoft.com/korea/technet/security/guidance/peap_int.asp)(https://www.microsoft.com/korea/technet/security/guidance/peap\_int.asp)에서 추가 정보를 볼 수 있습니다. ###### EAP-TLS 서버 요구 사항 앞에서 간략하게 언급한 바와 같이 EAP-TLS를 사용하려면 최소한 4대의 서버(분산된 환경 또는 대규모 환경인 경우 그 이상)가 필요합니다. 그 중 2대는 중복 IAS(Internet Authentication Service) 서버로 사용(RADIUS의 MS 구현)되고 나머지 2대는 기본 인증서 인프라(PKI)의 일부가 됩니다. 2대의 인증서 서버 중에서 루트 인증 기관(CA)은 독립적으로 실행되고 루트 인증서를 보호할 수 있도록 네트워크에서 분리된 상태를 유지합니다. **표 3. 루트 CA 서버의 권장 하드웨어 요구 사항**

구성 요소 요구 사항
CPU 733 MHz 이상의 단일 CPU
메모리 256MB RAM
네트워크 인터페이스 없음(또는 사용 안 함)
디스크 저장소 IDE 또는 SCSI RAID 컨트롤러 RAID 1 단일 볼륨(C 드라이브)으로 구성된 18GB HDD 2개 데이터 전송을 위한 로컬 이동식 저장소(루트 인증서)

테이블에 표시된 것과 같이, 루트 CA를 위한 Windows Server 2003 Standard Edition의 일반 요구 사항은 매우 낮은 편이기 때문에 기업 내에 사용되는 저사양의 PC를 사용해도 구축할 수 있으며 필요한 경우 가상 시스템으로도 만들 수 있습니다. 컴퓨터실에서 물리적으로 손쉽고 안전하게 보관할 수 있기 때문에 랩톱을 사용하는 것이 효율적일 수도 있습니다. 루트 CA를 만드는 데 어떤 접근 방법을 사용하든, 해당 컴퓨터를 안정적으로 시작하고 저장할 수 있는지 여부를 확인하는 것이 중요합니다.

발행 CA 하드웨어 요구 사항도 이와 비슷하지만 추가적인 저장소 요구 사항이 있으며 서버를 네트워크에 연결하지 않아도 됩니다. 이 서버는 발행되는 모든 인증서를 저장해야 하기 때문에 1000명의 사용자를 위한 최소 2GB의 하드 드라이브 용량을 구축하는 것이 좋습니다.

RADIUS 서버 요구 사항은 RADIUS 서버가 WLAN 기능을 유지 관리하는 데 중요한 역할을 하며 짧은 시간 동안에 많은 인증 시도를 처리해야 할 수 있기 때문에 약간 더 까다롭습니다. 따라서 수천 명의 무선 클라이언트를 수용할 수 있는 환경에 알맞은 강력한 하드웨어 플랫폼이 필요합니다. 또한 Windows Server 2003 Standard Edition을 사용해도 CA를 구성할 수 있지만 Standard Edition은 최대 50개의 RADIUS 클라이언트만 지원할 수 있기 때문에 Enterprise Edition으로 IAS를 구성하는 것이 좋습니다.

이 밖에도 도메인 컨트롤러에 필요한 기존의 강력한 서버 플랫폼을 사용하여 추가 서버 하드웨어에 대한 필요성을 줄일 수 있도록 IAS를 도메인 컨트롤러에 설치하는 것이 좋습니다. 실제로 도메인 컨트롤러에서 IAS를 사용하면 사용자 인증을 위해 도메인 컨트롤러와 IAS 간에서 발생하는 네트워크 트래픽이 줄어들어 IAS의 성능을 높일 수 있습니다.

RADIUS 서버 요구 사항을 결정할 때는 원격 위치뿐만 아니라 장애 조치와 중복도 고려해야 합니다. IAS의 최소 권장 요구 사항은 2개이지만, 많은 원격 사무실을 운영하는 기업인 경우에는 그러한 위치에 IAS 서버가 필요할 수 있습니다. 또한 서버 중복 또는 로드 균형 조정을 위해 더 높은 요구 사항이 필요할 수도 있습니다.

다기능 서버를 RADIUS 서버로 사용하는 부분에 대한 권장 사항은 없지만 그러한 서버에 발생할 수 있는 추가적인 부하 및 그러한 요구의 특성을 고려하는 것이 중요합니다. RADIUS 서버는 모든 무선 클라이언트가 짧은 시간 내에 연결을 시도하는 상황을 처리하도록 확장할 수 있어야 합니다.

인증서

어떤 WPA 방법을 사용하여 WLAN을 보호하든 해당 솔루션의 일부로 일정한 형식의 인증서가 있어야 합니다. PEAP의 경우에만 인증 서버에 인증서가 있어야 하므로 타사 인증서 서비스를 사용하여 필요한 인증서를 제공할 수 있으며, 그에 따라 PKI를 구현할 필요가 없습니다. 이런 이유로 PEAP 방법은 인증서 인프라를 구현하고 지원하는 데 필요한 전문 기술이나 리소스가 부족한 소규모 회사에 매우 적합합니다.

인증서 서비스를 사용하여 Windows 기반의 EAP-TLS를 구현하는 경우에는 인증서 발행을 지원하는 기본 PKI가 없어도 됩니다. 하지만 모든 클라이언트에 RADIUS 서버로 인증을 설정할 인증서가 있어야 하므로 규모가 아주 작은 회사가 아니라면 타사 인증서를 사용하는 데 막대한 비용이 소요될 수 있습니다. 따라서 인증서 서비스와 PEAP를 결합하여 사용하는 방법도 고려해야 합니다.

회사에 PKI가 있으면 의사 결정 프로세스가 더 간단해질 것입니다. 결국 구성 요소가 이미 구비되어 있으면 해당 구성 요소를 사용하여 WLAN 보안에 가장 안전한 옵션을 구현할 수 있습니다. PKI 구현이 설정되지 않은 경우에도 중소 기업은 다음과 같은 구현을 사용할 수 있는 다른 응용 프로그램에 대해 인증서 인프라에 투자하는 것이 현명하다는 사실을 알 수 있습니다.

  • 코드 서명

  • 전자 메일 메시징 보호

  • 웹 콘텐츠 전달 보호

  • VPN 보안

  • 암호화 파일 서비스

필요한 모든 사항을 고려할 때 EAP-TLS 또는 PEAP 중 하나와 함께 인증서 서비스를 사용하는 방법이 중소 기업에 가장 적합한 방법이므로 이 문서에서는 이에 대해 집중적으로 논의하겠습니다.

CPS(Certificate Practices Statement) 만들기

PKI의 초기 계획에는 인증서를 비즈니스 환경에서 사용하는 방법을 기록한 문서가 포함되어야 합니다. 진행 상황에 따라 이러한 의사 결정을 수정할 수는 있지만 공식 인증서 정책 문서에 해당 의사 결정 사항을 명시해야 합니다.

공식 용어로 인증서 정책이란 PKI 운영의 기준이 되는 일련의 규칙입니다. 이 정책에는 일반 보안 요구 사항과 함께 특정 조직 그룹이나 응용 프로그램에 대한 인증서 적용 관련 정보가 기록됩니다. CPS에는 기업이 발행하는 인증서를 관리하는 데 사용하는 시행 방법이 요약되어 있습니다. 또한 비즈니스 시스템 인프라와 운영 절차 정책을 고려하여 인증서 정책을 해석하는 방법을 설명합니다. 인증서 정책은 기업 단위의 문서이지만 CPS는 CA에 특정한 것이고 CA는 동일한 직무를 수행할 경우 공통 CPS를 가질 수 있습니다.

일부 비즈니스의 경우 인증서 시행 문서는 운영하는 사업을 규제하는 규정 요구 사항에 따라 반드시 작성해야 하는 법적 문서로, 문서를 만드는 과정에 법적 지원이 필요합니다. 그러나 비즈니스가 이러한 요구 사항의 규제를 받지 않을 경우에도 이 문서를 만드는 것이 좋습니다.

인증 기관 계층 구조

이 가이드에 지정된 디자인은 단일 내부 루트의 계층 구조적 신뢰 모델을 사용합니다. 이 방법에는 여러 가지 장단점이 있으므로 이러한 특정 방법이 구현할 비즈니스에 적합한지 여부를 결정하려면 심도 있는 논의를 거쳐야 할 수 있습니다. 이 항목에 대한 자세한 내용은 Windows Server 2003 Deployment Kit의 "Designing a Public Key Infrastructure (영문)"(https://technet2.microsoft.com/WindowsServer/en/library/b1ee9920-d7ef-4ce5-b63c-3661c72e0f0b1033.mspx)을 참조하십시오.

그림 2. 인증 기관 계층 구조

루트 인증 기관 보호

루트 CA가 네트워크에 연결되지 않은 "무선 형태"로 보호되지 않는 경우에는 Microsoft에서 구현하는 EAP-TLS가 작동하지 않습니다. 엔터프라이즈 루트 CA 디자인 대신 이러한 독립형 루트 CA 디자인을 사용하는 데는 충분한 보안상의 이유가 있습니다. 따라서 이는 일반적으로 PKI 구현에 권장되는 방법입니다.

이 방법이 리소스를 낭비하는 것처럼 보일 수도 있으므로 다른 방법을 사용하여 네트워크에 연결되지 않는 루트 CA를 만드는 데 사용되는 하드웨어의 일부를 다시 배포할 수도 있습니다. 제안되는 방법은 다음과 같습니다.

  • 루트 인증서를 만들어 발행 CA에 배포한 후에 루트 CA에서 하드 드라이브를 제거하여 다시 필요할 때까지 안전하게 보관할 수 있습니다. 이 방법의 단점은 루트 CA가 필요할 경우 해당 드라이브의 하드웨어를 다시 사용해야 한다는 점입니다.

  • 루트 인증서를 만들어 발행 CA에 배포한 후에 백업을 통해 서버의 이미지를 만들어 테이프나 다른 오프라인 미디어에 저장하여 서버 하드웨어를 다시 사용할 수 있습니다. 다시 필요할 경우 해당 하드웨어를 다시 사용하기 때문에 동일한 문제가 발생하게 됩니다.

  • 가상 서버, 가상 PC 또는 다른 종류의 가상 시스템 소프트웨어를 사용하여 루트 CA를 만듭니다. 루트 인증서를 만들고 배포한 후에 가상 시스템 이미지를 오프라인 저장소에 저장하고 다시 필요할 경우에 사용할 수 있습니다. 이 방법에 하드웨어 요구 사항을 충족하는 회사의 표준 데스크톱 시스템과 같은 표준 일반 플랫폼을 사용할 경우 루트 CA가 다시 필요할 때 필요한 하드웨어를 쉽게 다시 사용할 수 있습니다.

  • 전년도에 사용하던 랩톱에 오프라인 루트 CA를 만들고 컴퓨터실에 안전하게 보관합니다. 따라서 폐기될 수도 있는 하드웨어 리소스를 재활용할 수 있습니다.

인터넷 인증

IAS(인터넷 인증 서비스)는 RADIUS 및 프록시 서버를 Microsoft에서 구현한 것입니다. IAS는 다양한 네트워크 연결의 중앙 인증, 권한 부여 및 계정을 수행합니다. 또한 중앙 인증, 권한 부여 및 계정 전달자로 다른 RADIUS 서버와 함께 사용하거나, 라우팅 및 원격 액세스 서버 등의 다른 VPN 서버 또는 무선 액세스 지점 등의 다른 네트워크 인프라와 함께 사용할 수도 있습니다.

IAS 인프라의 배포 계획을 개발할 때는 IAS 기반의 RADIUS 인프라 가치를 최대한 활용하는 것이 중요합니다. 이는 격리된 단일 네트워크에 대한 액세스를 제공하는 것이 아니기 때문입니다. 따라서 IAS 인프라를 계획하여 배포하려면 Active Directory 등의 중앙 계정 데이터베이스 사용을 비롯하여 네트워크 액세스 관리에 중앙 서비스를 사용할지 여부를 결정해야 하고, 현재 및 향후 조직의 요구 사항을 충족해야 합니다. 즉, IAS 인프라는 단순한 임시 방편이 아니라 전술적인 측면을 고려하여 배포해야 합니다.

이 가이드에서는 보안 무선 인프라와 관련된 IAS 계획 및 배포에 대해서만 다룹니다. 기타 IAS 계획과 배포 가능성 및 문제에 대한 내용은 Internet Authentication Service (영문) 홈 페이지(www.microsoft.com/technet/itsolutions/network/ias/default.mspx)의 "Deployment Resources" 섹션을 참조하십시오.

기존 RADIUS 구현

이 솔루션을 기존 RADIUS 구현과 통합할 수 있지만 이 가이드에서는 통합 과정에 대해 설명하지 않습니다. 대부분의 경우 이 가이드에 설명된 기능에 대해서는 IAS를 사용하는 것이 유리합니다. 이를 위해 이전 플랫폼을 Windows 2003 Server로 업그레이드하여 핵심 RADIUS 서버로 사용하거나, 기존 RADIUS 서버를 수정하여 RADIUS 트래픽을 새로운 Windows Server 2003 기반의 RADIUS 서버로 위임할 수 있습니다.

기존 RADIUS 인프라를 Windows Server 2003 기반의 RADIUS 서버로 마이그레이션하는 작업에 대한 자세한 계획 지침은IAS Technical Reference (영문) 페이지(https://technet2.microsoft.com/WindowsServer/en/Library/8f5c89d5-fdaf-430c-9ef4-318f8c15baf11033.mspx)를 참조하거나 Microsoft 계정 담당자 또는 해당 Microsoft Consulting Services 전문가에게 문의하십시오.

RADIUS 서버 장애 조치 및 로드 균형 조정

RADIUS는 802.1X 무선 보안 솔루션의 핵심 구성 요소이므로 무선 네트워크의 가용성은 RADIUS 서버의 가용성에 좌우됩니다. 따라서 무선 네트워크를 지원하는 RADIUS 솔루션은 유선 네트워크에 필적하는 가용성과 성능을 보장하기 위해 안정적이고 응답성이 뛰어나야 할 뿐 아니라 충분한 성능을 갖추어야 합니다. 따라서 ISA는 일반적으로 기존 도메인 컨트롤러에 설치하는 것이 좋습니다.

로드 균형 조정 전략을 결정하기 전에 802.1X가 무선 액세스 지점과 RADIUS 서버 간의 RADIUS 내에 EAP(EAP-RADIUS)를 구현한다는 점을 이해해야 합니다. RADIUS가 UDP를 사용하기는 하지만 EAP는 RADIUS 내에서 터널링되는 세션 지향 프로토콜입니다. 즉, 단일 인증 작업을 구성하는 여러 개의 EAP-RADIUS 패킷은 동일한 RADIUS 서버로 반환되어야 합니다. 그렇지 않으면 특정 인증 시도가 실패하게 됩니다.

무선 네트워킹의 경우 IAS 서버에서 로드 균형 조정과 장애 조치를 수행하는 방법에는 두 가지가 있습니다. 첫 번째 방법은 RADIUS 서버 그룹에서 IAS 프록시 서버를 사용하는 것이고, 두 번째 방법은 무선 액세스 지점 하드웨어 설정을 통해 주 및 보조 RADIUS 서버를 구성하는 것입니다. 다음 표에는 각 접근 방법의 장단점이 나열되어 있습니다.

표 4. EAP에 대한 RADIUS 장애 조치 및 로드 균형 조정

방법 장점 단점
RADIUS 서버 그룹을 사용한 IAS 프록시
  • 장애 조치 및 장애 복구로 RADIUS 서비스 장애 검색
  • 트래픽 속성에 따라 트래픽 부하 분산
  • 로드 균형 조정을 수행하는 동안 EAP 세션 상태 유지
  • 우선 순위 및 가중치 설정에 따라 서버에 구성 가능한 요청 배포
  • 추가 IAS 서버가 필요함
  • 주 및 보조 프록시 RADIUS 서버 주소를 구성해야 함
무선 액세스 지점의 주 및 보조 RADIUS 서버 설정
  • 소규모 환경에 적합한 단순한 구성
  • 무선 액세스 지점에서 트래픽 실패를 검색하고 장애 조치 수행
  • 기본적인 무선 액세스 지점 기능 사용
  • 주 및 보조 RADIUS 트래픽 분산을 위해 추가 계획 및 모니터링 오버헤드가 필요함
  • 일부 무선 액세스 지점은 장애 복구 기능을 지원하지 않으므로 트래픽 부하가 분산되지 않을 수 있음

대기업은 RADIUS 서버 그룹에 구성된 RADIUS 프록시를 사용하여 RADIUS 서버의 부하를 분산하는 것을 고려해야 합니다. 이는 가중치 및 우선 순위 값 외에도 RADIUS 트래픽 유형 및 RADIUS 특성을 포함하여 여러 가지 구성 가능한 항목을 기반으로 트래픽을 분산할 수 있는 유연성을 제공합니다. 이 유형의 아키텍처는 관리 측면의 요구 사항을 줄여 주는 동시에 인증 요청 서비스의 유연성과 확장성을 극대화합니다.

무선 액세스 지점에 기본 제공되는 단순한 RADIUS 서버 장애 조치 기능은 대부분의 기업에 충분한 복원 수준을 제공하면서도 프록시 서버 그룹을 사용하는 것만큼 복잡하지는 않습니다. 그러나 이 아키텍처에서 RADIUS 프록시 서버 기반의 장애 조치 및 로드 균형 조정 솔루션으로 마이그레이션하는 경로는 비교적 단순하기 때문에 이 솔루션을 어느 정도 확장할 수도 있습니다. 소규모 또는 제한된 무선 영역만을 고려하는 회사에서는 이 솔루션을 쉽게 구현하여 효과를 얻을 수 있습니다. 단, 무선 네트워크 규모와 복잡도가 증가하게 되면 관리 및 구현 노력도 함께 증가하게 됩니다. 모든 서버에서 효과적인 로드 균형 조정을 유지하려면 각 장치에 세심한 모니터링과 계획이 필요하기 때문입니다.

그림 3. RADIUS WLAN 장애 조치 및 로드 균형 조정 방법

무선 액세스 지점의 기본 제공 기능인 로드 균형 조정에서는 다른 액세스 지점 집합을 보조 서버로 하여 주 RADIUS 서버를 사용하기 위해 각 위치에서 무선 액세스 지점의 절반 정도를 구성하게 됩니다. 무선 액세스 지점의 나머지 절반은 그림 3에 표시된 것과 같이 주 및 보조 필드에서 역 할당을 사용합니다. 다른 지점에 비해 일부 액세스 지점에 더 많은 부하가 발생하므로 오버헤드가 높아지며 그에 따라 효과적인 로드 균형 조정 수준을 얻고 유지하려면 많은 모니터링 작업을 수행해야 합니다.

RADIUS 로깅 요구 사항

IAS 서버에서는 두 가지 선택적 이벤트를 로깅할 수 있습니다.

  • 인증 시도의 성공 및 실패

  • RADIUS 인증 및 계정 정보

인증 이벤트는 장치와 사용자가 WLAN에 액세스할 때 생성되고 IAS에서는 이를 Windows Server 2003 시스템 이벤트 로그에 기록합니다. 이러한 이벤트는 문제 해결을 위해서는 물론 보안 감사/침입 차단 시스템의 일부로도 유용하게 활용할 수 있습니다. 성공 이벤트와 실패 이벤트에 모두 이러한 이벤트를 사용해야 하지만, 이후에 필터링을 통해 시스템 이벤트 로그 오버플로가 발생하지 않도록 해야 합니다. RADIUS 인증 요청 로깅을 사용하면 보안상 필요하지 않은 이벤트를 활용할 수 있습니다.

중앙 또는 분산 IAS 서버

대부분의 중소 기업에서는 고속 WAN 연결을 원격 시설로 복원하며, RADIUS 트래픽은 WAN 링크 및 전화 접속 연결을 통해 작동하도록 되어 있어 많은 대역폭을 소모하지 않으므로 이러한 중소 기업에서는 중앙 IAS 서버 아키텍처를 기반으로 디자인을 시작하는 방법을 고려해야 합니다. 중앙 집중식 디자인은 기본적인 중복 기능과 기본 고속 WAN 인프라가 제대로 갖춰진 경우 매우 경제적입니다.

하지만 기존 WAN 링크의 현재 용량을 분석하여 최상의 옵션인지 여부를 확인하는 데 많은 주의를 기울여야 합니다. DHCP 트래픽 등의 다른 통신에서는 트래픽이 많이 발생하는 연결에서 802.1X 인증 시도를 완료할 때까지 대기하는 동안 시간이 초과될 수 있기 때문입니다. IAS 서버와 도메인 컨트롤러 간의 통신에는 네트워크 액세스 권한 및 그룹 구성원 자격을 확인하는 동안 시간이 초과되는 것을 방지하기 위해 강력한 네트워크 연결이 필요하므로 중앙 IAS 아키텍처를 사용할지 여부를 고려할 때는 클라이언트 연결 외에 다른 요소도 고려해야 합니다.

일부 회사에서는 중복되는 고대역폭 WAN 연결 및 복잡한 네트워크 장비와 관련된 비용 문제로 인해 중앙 아키텍처를 활용할 수 없는 경우도 있습니다. 이러한 회사는 특히 분산 서버 인프라가 구비된 경우 분산 IAS 디자인을 사용할 것입니다.

또한 다음 그림과 같이 인프라를 지원할 수 있는 사이트에 IAS 서버를 전략적으로 배치하고, 기본 서버 기반이 없는 지사에 인증을 제공하는 서버를 사용하는 두 가지 방법을 혼합한 접근 방식도 있습니다.

그림 4. IAS WLAN 인프라 혼합 방법

이 가이드에서는 로컬 및 원격 요청을 모두 서비스하는 2대의 RADIUS 서버를 사용하여 대규모 허브 사무소를 구성하는 지침과, 선택적인 단일 서버 지사와 함께 대규모 본사를 구성하는 지침을 제공하여 세 가지 모델을 모두 설명합니다.

참고   서버 인프라 없이 원격 사무소에서 WLAN에 액세스하는 것은 WAN의 가용성에 따라 결정됩니다.

IAS 서버 배치 및 공동 배치 시 고려 사항

WLAN 서비스에 대한 액세스 상태를 유지하려면 각각의 Active Directory 포리스트에 RADIUS 서버가 2대 이상이어야 합니다. 이러한 기본 요구 사항 외에도 필요한 서버 수를 결정하는 요소와 다른 서버 기능과 함께 배치할 수 있는지 여부 등 여러 가지 다른 요소도 고려해야 합니다.

일반적으로 IAS 서버를 배치할 때는 도메인 컨트롤러 배치를 따라야 합니다. 즉, 사무소의 도메인 서비스가 다른 사무소의 고속 WAN 링크에 따라 좌우된다면 원격 RADIUS 서버를 사용해야 할 것입니다. 이미 자체 도메인 컨트롤러가 있는 대규모 사무소에는 사용 가능한 WAN 링크에 따라 결정되는 위치의 장애 조치를 수행할 수 있는 1대 이상의 RADIUS 서버만 있으면 됩니다. RADIUS 서버 배치를 계획할 때는 로컬 사용자 인증의 안정성과 추가 트래픽 발생으로 인한 인증용 도메인 컨트롤러의 배치를 위해 WAN 링크 용량을 신중하게 진단해야 합니다. 또한 성능을 향상하려면 RADIUS 서버를 포리스트의 루트 도메인에 배치하여 Kerberos 작업을 최적화해야 합니다.

일부 소규모 사무소에는 추가 서버 하드웨어를 지원하는 공간이나 인프라가 없으므로 필요한 경우 원격지에 추가 서버를 배치하는 것이 적절한지 여부를 고려해야 합니다. IAS 서버와 Active Directory 도메인 컨트롤러를 공동 배치하면 이러한 문제를 해결할 수 있습니다. 다음 표에서는 이 방법의 장단점에 대해 설명합니다.

표 5. IAS 및 도메인 컨트롤러 공동 배치 시 고려 사항

IAS 위치 장점 단점
도메인 컨트롤러에 공동 배치
  • 사용자 및 컴퓨터 인증과 권한 부여 성능 향상
  • 추가 서버 하드웨어의 필요성 감소
  • IAS 관리 그룹과 도메인 관리자가 구분되지 않음
  • 공동 배치한 서비스와 관련된 오류나 성능 문제를 기본적으로 구분하지 못함
독립형 IAS 서버
  • IAS 관리와 도메인 관리자가 구분됨
  • IAS 부하 및 동작이 도메인 컨트롤러에 영향을 주지 않음
  • 추가 서버 하드웨어가 필요함

이 표에서 알 수 있듯이 많은 회사들은 도메인 컨트롤러 기능을 자체 서버로 격리하는 기존 정책을 가지고 있는데 이는 네트워크 환경에 매우 중요하기 때문입니다. IAS 관리는 로컬 Windows 관리자 그룹 기능과 기본적으로 구분되지 않으므로 양쪽 관리 그룹 사이에 직무 구분이 필요한 경우 도메인 컨트롤러에 IAS 서비스를 배치하는 것과 관련하여 발생하는 보안 문제도 고려해야 합니다. 이런 문제는 IAS 서비스를 공동 배치할 가능성을 결정하기 전에 먼저 고려해야 합니다. 그러나 공동 배치할 경우에는 성능상의 이점을 얻을 수 있으며 특히 원격지에서는 비용 면에서 확실한 장점을 누릴 수 있습니다.

원격 사무소에 서버 하드웨어를 추가할 경우 비용 문제를 상쇄하기 위해 원격지에 있는 기존 도메인 컨트롤러를 사용할 수 있습니다. IAS 서버는 기존 도메인 컨트롤러에 직접 연결하거나 기존 도메인 컨트롤러에 가상 시스템을 추가할 수 있습니다.

서버 부하 및 하드웨어 요구 사항 평가

잠재적 서버 부하를 진단하고 계획할 때는 최악의 시나리오를 고려해야 합니다. 특히 잠재적 WLAN 사용자가 모두 장애 조치 이벤트 중 단시간 내에 인증을 수행해야 할 경우 등을 고려해 보십시오. 물론 최적의 디자인은 복원에 필요한 최소한의 서버를 배포하면서 향후 확장에 필요한 여지를 남기는 것입니다.

IAS 서버 부하 및 요구 사항을 계획할 때 고려해야 할 정보는 다음과 같습니다.

  • 인증과 계정이 필요한 사용자 및 장치 수

  • EAP 유형 등의 인증 옵션 및 재인증 빈도

  • 로깅 세부 사항 및 IAS 소프트웨어 추적 등의 RADIUS 옵션

이 솔루션에서 EAP-TLS 인증서 서비스와 함께 WPA 또는 WPA2를 사용할 경우, WPA와 WPA2는 WEP와 달리 세션 키를 새로 고치기 위해 재인증을 시행할 필요가 없으므로 오버헤드가 줄어듭니다. 또한 EAP-TLS에서는 초기 인증을 시행할 때마다 CPU 집약적인 공개 키 작업을 수행해야 하며 캐시된 자격 증명이 만료될 때까지 기본적으로 8시간마다 한 번씩 이후에 로그온할 때마다 신속히 다시 연결하기 위해 캐시된 자격 증명을 사용합니다. 또한 클라이언트가 한 RADIUS 서버에 인증하는 무선 액세스 지점에서 다른 인증 서버에 인증하는 무선 액세스 지점으로 로밍할 때 재인증이 발생한다는 점에 주목해야 합니다. 재인증은 각 인증 서버에서 한 번만 발생하며 사용자에게 투명한 방식으로 진행됩니다.

IAS 서버 용량을 산정할 때는 잠재적 부하 수치인 초당 인증 수를 사용하는 것이 유용합니다. 다음 표는 Intel Pentium 4 2GHz CPU 플랫폼에 Active Directory와 함께 설치된 IAS 서버의 초당 인증 용량 산정 수치를 나타냅니다.

표 6. 초당 인증 수

인증 유형 초당 인증 수
새로운 EAP-TLS 인증 36
오프로드 카드가 지원되는 새로운 EAP-TLS 인증 50
신속히 재연결되는 인증 166
**참고**   이 표의 정보는 용량 계획을 위한 지침으로 사용할 수 있는 산정 수치로만 간주되어야 합니다. 이 표에 따르면 장애 조치 또는 최대 요구 이벤트 발생 시 해당 서버가 초당 36개의 인증을 새로 처리할 수 있으므로 3초에 100명의 사용자를 인증할 수 있습니다. 또한 인증 시 디스크 기반 로깅의 효과를 고려해야 합니다. 세부 로깅이 인증 작업을 추적하는 데 사용될 경우 디스크 하위 시스템의 속도가 느리면 인증 시 지장을 줄 수 있습니다. 각 IAS 서버에서 적절한 응답 시간을 유지하려면 빠른 디스크 하위 시스템을 사용해야 합니다. ##### WPA 802.11 인증 무선 통신을 보호하기 위해 사용자 및 장치 인증을 제공하여 인증서 인프라와 RADIUS를 사용하는 방법을 다루었으므로 이제 무선 장치 간에 전송되는 데이터가 탐색과 기타 위험으로부터 어떻게 보호되는지 살펴보겠습니다. 무선 전송 사용법은 특히 포트 보안이 사용되는 경우 케이블이나 패치 패널을 통하지 않고 훨씬 적은 노력으로도 공중에서 전송되는 데이터를 가로채기 때문에 항상 유선 통신보다 안전성이 떨어지는 것으로 간주되었습니다. 근본적으로 불안정한 무선 통신의 특성을 해소하려면 잠재적 도청자가 데이터를 가로채 쉽게 읽을 수 있는 정보를 만들지 못하도록 데이터를 암호화해야 합니다. 무선 암호화의 초기 WEP 사양은 이 작업에 부적절한 것으로 밝혀졌기 때문에 임시 방편으로 802.11i 사양의 하위 집합인 WPA가 만들어졌으나 당시에는 사용이 보류되었습니다. 최종적으로 WPA2가 현재 공식 802.11i 표준의 완전한 구현으로 제작되었습니다. WPA와 WPA2의 주요 차이점은 암호화 방법인데 WPA는 TKIP를 사용하고, WPA2는 좀 더 안전한 AES-CCMP 표준을 사용합니다. 이 가이드에 제공된 솔루션을 사용하여 WEP 또는 WPA를 보호할 수는 있지만 관리 측면에서 적합한 경우 무선 통신에 사용할 수 있는 가장 안전한 최상의 보안 형태를 보장하려면 WPA2를 사용하는 것이 좋습니다. 이외의 경우에는 이 가이드에 제공된 솔루션과 함께 WPA를 사용하여 적절한 수준의 보안을 얻을 수 있습니다. ###### 클라이언트 요구 사항 이 가이드에 소개된 솔루션은 Windows XP Professional SP2 또는 Windows XP Tablet Edition을 사용하는 무선 가능 클라이언트 컴퓨터에 적합하게 디자인되었습니다. 이러한 버전의 Windows 운영 체제는 기본적으로 802.1X와 WLAN 지원을 제공합니다. 또한 Windows XP 기반 클라이언트는 자동 인증서 등록 및 갱신 기능을 제공하므로 인증서 기반 솔루션이 인증서 인프라와 결합될 경우 매우 경제적으로 운용할 수 있습니다. Windows XP SP2에서 기본적으로 WPA 지원을 제공하지만 Windows XP SP2 기반 클라이언트에서 IEEE 802.11i WPA2 지원을 사용하려면 추가 업데이트를 설치해야 합니다. 다운로드 지침과 함께 추가 업데이트에 대한 자세한 내용을 보려면 [ Windows XP 서비스 팩 2용 WPA2/WPS IE 업데이트를 사용할 수 있다](https://support.microsoft.com/default.aspx?scid=kb;ko-kr;893357)(https://support.microsoft.com/default.aspx?scid=kb;ko-kr;893357)를 참조하십시오. ###### 서버 인프라 요구 사항 앞서 논의한 대로 이 솔루션을 구현하려면 Windows Server 2003의 인증서 서비스와 IAS 구성 요소를 사용해야 합니다. 현재 802.1X WLAN에 특정한 인증서 서비스와 IAS의 Windows Server 2003 구현을 통해 지원되는 기본 제공 기능이 몇 가지 있습니다. IAS와 인증서 서비스를 이전 버전의 Windows에 배포할 수도 있지만 이 가이드는 Windows Server 2003 Active Directory 환경을 고려하여 작성되었습니다. ###### 무선 액세스 지점 요구 사항 이 가이드에서는 WLAN 솔루션의 보안 요소를 집중적으로 논의하므로 무선 액세스 지점 하드웨어의 배포, 배치 또는 채널 선택에 관한 지침은 다루지 않습니다. 특정한 무선 액세스 지점 하드웨어 문제, 구성, 배치 지침에 대한 자세한 내용은 공급업체의 지침 자료나 웹 사이트를 참조하십시오. 이 솔루션은 IEEE 802.11i WPA2로 인증되고 기본적으로 장애 조치/장애 복구 기능을 제공하는 무선 액세스 지점 하드웨어를 사용할 경우 가장 안전합니다. 이 지침을 대폭 수정하지 않고도 WPA 인증 장비를 사용하여 이 솔루션을 구현하고 매우 뛰어난 보안 수준을 계속 유지할 수도 있습니다. 단, WEP 표준으로 이 솔루션을 구현할 수도 있지만 이런 방법은 권장되지 않으며 이 가이드에서 지원되지도 않습니다. #### 배포 및 관리 이 섹션에는 솔루션에 필요한 서버와 서비스의 설치 및 구성에 관한 단계별 지침이 포함되어 있지만 Windows Server 2003 및 Windows XP Professional 등의 운영 체제에 필요한 실제 설치 및 구성 단계는 수록되어 있지 않습니다. 또한 대부분의 기업이 구축 프로세스와 강화 지침을 수립해 놓은 것으로 가정합니다. ##### 인증서 이 섹션에서는 PKI 설치에 관한 세부 지침을 제공하지만 서버 구축 및 강화 프로세스의 세부 사항은 포함되어 있지 않습니다. 해당 절차에 필요한 표준 프로세스가 이미 수립되어 있는 것으로 가정하기 때문입니다. 또한 CA 서버가 이미 기본 이미지로 구성되어 있으며 이 단계의 솔루션 이전에 표준 조직 프로세스별로 강화되어 있는 것으로 가정합니다. **참고**   루트 CA는 네트워크에 연결되지 않으므로 네트워크 연결이 필요한 조직 서버 구축 및 강화 프로세스의 단계는 이러한 예외를 수용하도록 수정되어야 합니다. ###### 사용자 정의된 필수 구성 정보 다음 표에는 이 가이드의 뒷부분에 제공되는 솔루션 배포를 시작하기 전에 먼저 수집하거나 결정해야 할 조직 관련 매개 변수가 나와 있습니다. 가이드 전반에 걸쳐 설정 이름과 유사한 형식을 사용하여 설정을 설명하는 데 사용되는 자리 표시자도 확인할 수 있습니다. 예를 들어, Active Directory 포리스트 루트 도메인의 DNS 이름은 DomainName.com으로 표시될 수 있습니다. 기울임꼴로 표시된 값은 이 프로세스 중에 수집된 특정 조직 정보로 대체되어야 합니다. **표 7. 사용자 정의된 구성 정보**

구성 항목 참조 설정
Active Directory 포리스트의 DNS 이름    
포리스트 루트의 고유 이름(DN) Pkiparams.vbs  
도메인의 NetBIOS 이름    
루트 CA 작업 그룹의 NetBIOS 이름    
루트 CA의 서버 이름    
발행 CA의 서버 이름    
루트 CA의 X.500 CN    
발행 CA의 X.500 CN    
CA 인증서를 게시하는 데 사용되는 웹 서버의 정규화된 호스트 이름 Pkiparams.vbs  
###### 필수 솔루션에 규정된 구성 항목 다음 표에 나와 있는 설정은 다른 설정이 확정되는 경우가 아니면 변경할 필요가 없습니다. 여기에 나열된 설정을 변경하려면 먼저 이러한 매개 변수를 변경함으로써 발생할 수 있는 모든 영향 및 종속성의 변화를 완전하게 이해해야 합니다. **표 8. 솔루션에 규정된 구성 항목**

구성 항목 참조 설정
관리 역할 보안 그룹    
공개 키 서비스 구성 컨테이너 관리자 ca_setup.wsf Enterprise PKI Admins
CRL 및 CA 인증서를 엔터프라이즈 구성 컨테이너에 게시할 수 있는 관리 그룹 ca_setup.wsf Enterprise PKI Publishers
CA를 구성 및 유지 관리하고, 다른 모든 CA 역할 할당과 CA 인증서를 갱신할 수 있는 관리 그룹 ca_setup.wsf CA Admins
인증서 등록 및 해지 요청을 승인하는 관리 그룹(CA 담당자 역할) ca_setup.wsf Certificate Managers
CA 감사 및 보안 로그를 관리하는 관리 그룹 ca_setup.wsf CA Auditors
CA 백업을 관리하는 관리 그룹 ca_setup.wsf CA Backup Operators
IIS 구성    
CA 인증서 및 CRL 정보를 게시하는 데 사용되는 IIS 가상 디렉터리 이름 Pkiparams.vbs pki
IIS 가상 디렉터리에 매핑하는 발행 CA의 실제 경로 C:\CAWWWPub Pkiparams.vbs
공통 CA 매개 변수    
인증서 서비스 요청 파일의 드라이브 및 경로 C:\CAConfig Pkiparams.vbs
인증서 서비스 데이터베이스 로그의 드라이브 및 경로   %windir%\System32\CertLog
루트 CA 구성    
루트 CA 키 길이(참고 참조) 4096  
루트 CA 인증서 유효 기간(년) Pkiparams.vbs 16
루트 CA에서 발행한 인증서의 최대 유효 기간(년) Pkiparams.vbs 8
루트 CA CRL 게시 간격(월) Pkiparams.vbs 6
CRL 중복 기간(일) Pkiparams.vbs 10
루트 CA에 대한 델타-CRL 게시 기간(시간, 0 = 사용 안 함) Pkiparams.vbs 0
발행 CA 구성    
인증서 서비스 데이터베이스의 드라이브 및 경로   D:\CertLog
발행 CA 키의 길이   2048
발행 CA 인증서 유효 기간(년) Pkiparams.vbs 8
발행 CA 인증서의 최대 유효 기간(년) Pkiparams.vbs 4
발행 CA CRL 게시 간격(일) Pkiparams.vbs 7
CRL 중복 기간(일) Pkiparams.vbs 4
발행 CA에 대한 델타-CRL 게시 기간(일, 0 = 사용 안 함) Pkiparams.vbs 1
델타-CRL 중복 기간(일) Pkiparams.vbs 1
기타    
설치 스크립트 경로   C:\MSSScripts
**참고**   4096비트 길이의 키를 사용 중일 때 해당 키가 다른 장치 또는 타 공급업체의 이전 소프트웨어에서 사용되면 호환성 문제가 발생할 수 있습니다. 루트 CA에서 발행하는 인증서를 사용하는 모든 응용 프로그램은 이 길이의 인증서 키로 테스트하여 올바로 작동하는지 확인해야 합니다. 키 길이 호환성에 대한 문제가 우려되는 경우에는 루트 CA 키 길이를 2048비트까지 줄일 수 있습니다. ###### CA 서버에 구성 스크립트 설치 이 가이드에서 제공하는 지원 스크립트는 다음 섹션에서 설명하는 솔루션을 설치하는 데 도움을 주기 위한 것입니다. 이 스크립트는 각 CA 서버에 설치해야 하며 사용이 완료된 이후에도 서버 작동을 도울 수 있도록 삭제해서는 안 됩니다. 스크립트를 설치하려면 먼저 C:\\MSSScript라는 폴더를 만든 다음 스크립트를 복사하고 이 디렉터리에 붙여 넣으십시오. ###### 발행 CA 서버에서 IIS 설치 및 구성 인터넷 정보 서비스(IIS)는 Windows 이외의 클라이언트가 CA 인증서 및 CRL을 검색하는 다운로드 지점으로 사용됩니다. 루트 CA의 경우에는 네트워크에 연결되지 않기 때문에 이 서비스를 제공할 필요가 없지만 발행 CA는 이 서비스에 액세스할 수 있어야 합니다. IIS는 인증서 서비스 웹 등록 페이지를 호스팅하는 데에도 사용할 수 있지만 이 솔루션에서는 사용되지 않습니다. 발행 CA 이외의 다른 시스템에 웹 등록 페이지를 설치하는 경우 Active Directory의 서버 컴퓨터 개체에서 이 서버의 속성이 "위임용으로 트러스트"로 표시되도록 설정해야 합니다. IIS는 제어판의 구성 요소 추가/제거를 통해 액세스하는 Windows 추가 구성 요소 관리자를 사용하여 설치할 수 있습니다. 다음은 설치해야 하는 구성 요소의 목록입니다. - 응용 프로그램 서버 - 네트워크 COM+ 액세스 사용 - 인터넷 정보 서비스 - 공용 파일 - 인터넷 정보 서비스 관리자 - World Wide Web 서비스 **IIS를 설치하려면** 1. 명령 프롬프트에서 다음을 실행합니다. ``` Sysocmgr /i:sysoc.inf /u:C:\\MSSScripts\\OC\_AddIIS.txt ``` 이 명령은 추가 구성 요소 관리자에게 무인 설치 파일 C:\\MSSScripts\\OC\_AddIIS.txt에 지정된 구성 요소 구성을 다음과 같이 사용하도록 지시합니다. ``` \[Components\] complusnetwork = On iis\_common = On iis\_asp = On iis\_inetmgr = On iis\_www = On ``` **참고**    ASP(Active Server Pages)는 이 구성 파일에서 설정됩니다. 그러나 인증서 서비스 웹 등록 페이지가 필요하지 않은 경우에는 sysocmgr.exe를 실행하기 전에 **iis\_asp = on** 줄을 삭제하여 ASP를 해제해야 합니다. 이 설정은 필요한 경우 나중에 다시 사용할 수 있습니다. 2. 추가 구성 요소 관리자를 다음과 같이 다시 실행하여 설치된 구성 요소가 이전에 나열된 구성 요소와 일치하는지 확인합니다. ``` sysocmgr /i:sysoc.inf ``` 응용 프로그램 서버의 다른 하위 구성 요소는 필요하지 않으므로 선택할 필요가 없습니다. 발행 CA에서 AIA 및 CRL CDP 게시용 IIS 구성 CA 인증서 및 CRL 게시 지점(각각 AAA(기관 정보 액세스) 및 CDP(CRL 배포 지점)라고 함)으로 HTTP 위치를 사용하려면 IIS에 가상 디렉터리를 만들어야 합니다. **IIS에 가상 디렉터리를 만들려면** 1. 로컬 관리자 권한으로 IIS 서버에 로그온합니다. 2. CA 인증서 및 CRL이 위치할 **C:\\CAWWWPub** 폴더를 만듭니다. 3. 다음 표에 나와 있는 대로 폴더의 보안을 설정합니다. **표 9. 가상 디렉터리 권한** 
<table style="border:1px solid black;">
<colgroup>
<col width="33%" />
<col width="33%" />
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th style="border:1px solid black;" >사용자/그룹</th>
<th style="border:1px solid black;" >사용 권한</th>
<th style="border:1px solid black;" >허용/거부</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="border:1px solid black;">Administrators</td>
<td style="border:1px solid black;">모든 권한</td>
<td style="border:1px solid black;">허용</td>
</tr>
<tr class="even">
<td style="border:1px solid black;">System</td>
<td style="border:1px solid black;">모든 권한</td>
<td style="border:1px solid black;">허용</td>
</tr>
<tr class="odd">
<td style="border:1px solid black;">Creator Owners</td>
<td style="border:1px solid black;">모든 권한(하위 폴더 및 파일만)</td>
<td style="border:1px solid black;">허용</td>
</tr>
<tr class="even">
<td style="border:1px solid black;">Users</td>
<td style="border:1px solid black;">폴더 콘텐츠 읽기 및 나열</td>
<td style="border:1px solid black;">허용</td>
</tr>
<tr class="odd">
<td style="border:1px solid black;">IIS_WPG</td>
<td style="border:1px solid black;">폴더 콘텐츠 읽기 및 나열</td>
<td style="border:1px solid black;">허용</td>
</tr>
<tr class="even">
<td style="border:1px solid black;">Internet Guest Account</td>
<td style="border:1px solid black;">쓰기</td>
<td style="border:1px solid black;">거부</td>
</tr>
</tbody>
</table>

  1. IIS 관리 콘솔을 사용하여 기본 웹 사이트 아래에 새로운 가상 디렉터리를 만듭니다.

    • 가상 디렉터리 pki 이름 지정

    • 경로 C:\CAWWWPub 지정

  2. 가상 디렉터리 액세스 권한에서 스크립트 실행 옵션을 지웁니다.

  3. 가상 디렉터리에서 익명 인증을 사용할 수 있는지 확인합니다.

HTTP 게시 지점에 대한 DNS 별칭 선택
CDP와 AIA를 호스팅하는 IIS 서버를 확인하기 위해 일반 DNS 별칭(CNAME)을 만들어야 합니다. 이 DNS 별칭은 다음 장에서 CA에 대한 CDP 및 AIA 경로를 구성할 때 사용해야 합니다. 별칭을 사용하면 CA 인증서를 다시 발행하지 않아도 CA 게시 지점을 다른 서버 또는 네트워크 위치로 쉽게 이동할 수 있습니다.

기타 구성 및 운영 체제 구성 요소 항목

지금까지 설명한 구성 단계 외에도, 다음과 같은 권장 항목에 유의해야 합니다.

  • 루트 인증서 업데이트 서비스. CA의 루트 신뢰가 자동으로 업데이트되도록 하는 것은 바람직하지 않기 때문에 루트 인증서 업데이트 서비스는 해제해야 합니다. 이 서비스는 명령 프롬프트에서 다음을 실행하여 간단하게 제거할 수 있습니다.

        sysocmgr /i:sysoc.inf /u:C:\\MSSScripts\\OC\_RemoveRootUpdate.txt

    OC_RemoveRootUpdate.txt 파일에는 다음 줄이 포함되어 있습니다.

        \[Components\] rootautoupdate = off

  • 루트 CA가 네트워크에 연결되지 않았는지, 그리고 발행 CA에 인바운드 또는 아웃바운드 인터넷 연결이 없는지 확인하십시오.

  • 설치된 IIS에 서비스 팩 및 업데이트가 추가로 필요한지 확인하십시오.

  • Windows Server 2003 지원 도구를 설치하십시오. 필수적인 항목은 아니지만 이 도구는 특정 CA 운영이나 일반적인 문제 해결에 유용하게 사용할 수 있습니다.

  • CAPICOM을 설치하십시오. CAPICOM 2.1은 이 가이드와 함께 제공된 설치 및 관리 스크립트를 사용하기 위해 루트 CA와 발행 CA에 필요한 프로그램입니다. CAPICOM에 대한 자세한 내용 및 다운로드 링크를 보려면 www.microsoft.com/downloads/details.aspx?FamilyID=860ee43a-a843-462f-abb5-ff88ea5896f6&DisplayLang=ko를 참조하십시오.

PKI를 위한 Active Directory 준비

이 섹션에서 설명하는 Active Directory 도메인 인프라에 대한 기본적 요구 사항은 Microsoft Windows Server 2003 Active Directory 아키텍처를 기반으로 합니다. 사용 중인 Active Directory의 구현이 Windows 2000을 기반으로 하는 경우 다른 요구 사항이 필요할 수 있습니다. Windows 2000 기반 도메인 구조의 추가 요구 사항에 대한 자세한 내용은 Windows Server 2003에서 도메인 및 포리스트 기능 수준을 올리는 방법(https://support.microsoft.com/kb/322692)을 참조하십시오.

이 솔루션은 최소한 CA 서버가 설치된 도메인의 경우 Windows 2000 기본 모드 이상의 도메인 기능 수준을 요구합니다. 이 요구 사항이 필요한 이유는 이 솔루션이 Windows 2000 기본 모드 이상에서 사용할 수 있는 Active Directory 유니버설 그룹을 사용하기 때문입니다.

PKI 및 CA 관리 그룹 만들기
이 솔루션은 개별 관리 역할에 해당하는 여러 보안 그룹을 정의합니다. 이 접근 방법은 최소의 권한 보안 원칙과 연결하여 CA 관리 위임을 효과적으로 제어합니다. 그러나 어떤 조직 관리 모델과도 부합하지 않는다면 꼭 사용해야 할 필요는 없습니다.

도메인에 CA 관리 그룹을 만들려면

  1. 사용자 컨테이너에서 사용자와 그룹 개체를 만들 수 있는 권한이 있는 계정으로 도메인 구성원 컴퓨터에 로그온합니다.

  2. 다음 명령을 실행하여 도메인 CA 관리 그룹을 만듭니다.

        Cscript //job:CertDomainGroups C:\\MSSScripts\\ca\_setup.wsf

    이 스크립트를 실행하면 다음 표에 나열된 보안 그룹이 만들어집니다. 이 그룹은 도메인 사용자 컨테이너에 유니버설 그룹으로 만든 다음 기업 정책에 따라 보다 적절한 OU로 이동할 수 있습니다.

    표 10. 그룹 이름 및 목적

    그룹 이름 목적
    Enterprise PKI Admins 공개 키 서비스 구성 컨테이너 관리자
    Enterprise PKI Publishers CRL 및 CA 인증서를 엔터프라이즈 구성 컨테이너에 게시할 수 있습니다.
    CA Admins 다른 역할의 구성원을 결정하는 것을 비롯하여 CA에 대한 모든 관리 기능을 가집니다.
    Certificate Managers 인증서 발행과 해지를 관리합니다.
    CA Auditors CA에 대한 감사 데이터를 관리합니다.
    CA Backup Operators CA 키와 데이터를 백업하고 복원할 수 있는 권한을 가집니다.

이 가이드의 나머지 부분에 있는 설치 절차를 수행하려면 Enterprise PKI Admins, Enterprise PKI Publishers 및 CA Admins의 구성원인 계정을 사용하여 이러한 그룹을 적절한 계정으로 채워야 합니다. CA 관련 역할을 담당하는 사람이 한 명인 경우에는 하나의 계정을 모든 그룹에 할당할 수 있지만 대부분의 기업에서는 앞의 표에 나열되어 있는 정도는 아니더라도 일정 수준의 역할 분담이 이루어지고 있습니다. 다음 차트에서는 단순한 역할 분담을 사용하는 기업에 적용될 수 있는 공통적인 책임 구분을 보여 줍니다.

표 11. 단순한 관리 모델

관리 역할 그룹 구성원
CA Administrator Enterprise PKI Admins, CA Admins, Certificate Managers, Administrators
CA Auditor CA Auditors, Administrators
CA Backup Operator CA Backup Operators
##### 권장되는 도메인 OU 구조 PKI의 관리 및 운영과 관련된 많은 그룹과 사용자 계정이 있습니다. 수립된 정책에 따라 이러한 그룹 및 사용자를 특정 OU 구조에 구성해야 할 수 있습니다. 이러한 구조는 기존의 기업 지침에 따라 이미 결정되어 있을 수 있기 때문에 다음에서 제안하는 구조는 필요에 따라 수정할 수 있습니다. **인증서 서비스 OU 계층 구조를 만들려면** 1. OU를 만들고 해당 OU 내에 권한을 위임할 수 있는 권한이 있는 계정으로 로그온합니다. 2. 다음 표를 기반으로 OU 구조를 만듭니다. **표 12. OU 구조의 예**
조직 구성 단위 목적
인증서 서비스 상위 OU
\-인증서 서비스 관리 CA와 엔터프라이즈 PKI 구성을 관리하는 관리 그룹이 포함되어 있습니다.
\-인증서 템플릿 관리 개별 인증서 템플릿 관리를 위한 그룹이 포함되어 있습니다.
\-인증서 템플릿 등록 동일한 이름의 템플릿에 대해 등록 또는 자동 등록 권한을 부여 받은 그룹이 포함되어 있습니다. 이러한 그룹에 대한 관리는 템플릿 자체를 수정하지 않고도 적절한 직원에게 위임할 수 있습니다.
\-인증서 서비스 테스트 사용자 임시 테스트 계정이 포함되어 있습니다.
3. 인증서 서비스 OU 및 해당 하위 컨테이너에서 그룹을 만들거나 삭제할 수 있는 권한을 Enterprise PKI Admins 그룹에 부여합니다. 공개 키 서비스 컨테이너에 권한 부여 Enterprise PKI Admins가 해당 그룹 계정이 Enterprise Admins 그룹의 구성원이 아닌 경우에도 엔터프라이즈 CA를 설치하거나 인증서 템플릿을 구성할 수 있으려면 공개 키 서비스 컨테이너의 보안을 변경해야 합니다. 이러한 변경은 Enterprise PKI Publishers가 Enterprise Admin 권한 없이도 인증서 해지 목록이나 CA 인증서를 게시하는 데에도 필요합니다. 다음과 같은 내용을 변경하려면 Active Directory Enterprise Admin에 해당하는 계정을 사용해야 합니다. **Enterprise PKI Admins에 권한을 부여하려면** 1. Enterprise Admins 보안 그룹의 구성원으로 로그온합니다. 2. Active Directory 사이트 및 서비스 MMC 스냅인의 **보기** 메뉴에서 **서비스** 노드를 표시하고 공개 키 서비스 하위 컨테이너를 찾아 속성을 엽니다. 3. **보안** 탭에서 Enterprise PKI Admins 보안 그룹을 추가하고 이 그룹에 모든 권한을 부여합니다. 4. **고급 보기**에서 모든 권한이 이 개체 및 자식 개체 전체에 적용되도록 이 그룹의 권한을 편집합니다. 5. **서비스** 컨테이너를 선택하고 속성을 엽니다. 6. **보안** 탭에서 Enterprise PKI Admins 보안 그룹을 추가하고 이 그룹에 모든 권한을 부여합니다. 7. **고급 보기**에서 모든 권한이 이 개체에만 적용되도록 이 그룹의 권한을 편집합니다. **Enterprise PKI Publishers에 권한을 부여하려면** 1. Enterprise Admins 보안 그룹의 구성원으로 로그온합니다. 2. Active Directory 사이트 및 서비스 MMC 스냅인에서 **서비스** 노드를 표시하고 공개 키 서비스\\AIA 컨테이너의 속성을 엽니다. 3. **보안** 탭에서 Enterprise PKI Publishers 보안 그룹을 추가하고 이 그룹에 다음 권한을 부여합니다. - 읽기 - 쓰기 - 모든 자식 개체 만들기 - 모든 자식 개체 삭제 4. **고급 보기**에서 이러한 권한이 이 개체 및 자식 개체 전체에 적용되도록 이 그룹의 권한을 편집합니다. 5. 다음 컨테이너에 대해 2-4단계를 반복합니다. - 공개 키 서비스\\CDP - 공개 키 서비스\\인증 기관 Cert Publishers 그룹에 권한 부여 도메인 내의 모든 엔터프라이즈 CA 컴퓨터 계정은 Cert Publishers 보안 그룹에 위치합니다. 이 그룹은 이전 절차에서 언급된 CDP 컨테이너 내의 개체, 사용자 및 컴퓨터 개체에 권한을 적용하는 데 사용됩니다. CA를 설치할 때마다 해당 컴퓨터 계정을 이 그룹에 추가해야 합니다. Enterprise PKI Admins 그룹의 구성원이 엔터프라이즈 CA를 설치하려면 이 그룹의 권한을 변경해야 합니다. **Cert Publishers에 구성원 수정 권한을 부여하려면** 1. 발행 CA가 설치될 도메인의 Domain Admins 구성원으로 로그온합니다. 2. Active Directory 사용자 및 컴퓨터 MMC 스냅인을 엽니다. 3. MMC의 **보기** 메뉴에서 **고급 기능**이 선택되었는지 확인합니다. 4. Cert Publishers 그룹(기본적으로 사용자 컨테이너에 있음)을 찾아 그룹의 속성을 봅니다. 5. **보안** 탭에서 Enterprise PKI Admins 그룹을 추가하고 **고급** 단추를 클릭합니다. 6. 목록에서 Enterprise PKI Admins 그룹을 선택하고 **편집** 단추를 클릭합니다. 7. **속성** 탭의 **적용 대상** 상자에서 **이 개체만**이 선택되었는지 확인합니다. 8. 아래로 스크롤하고 **허용**열에서 **Write Members** 상자를 누릅니다. 9. 변경 내용을 저장하고 각 대화 상자에서 **확인**을 클릭하여 대화 상자를 닫습니다. 10. 인증서 서비스 구성 요소를 설치하기 전에 발행 CA 서버를 다시 시작합니다. 서버를 다시 시작하면 서버가 액세스 토큰에서 새 그룹 구성원을 선택할 수 있습니다. Enterprise PKI Admins에 복원 권한 부여 인증서 서비스를 설치하려면 엔터프라이즈 CA가 위치할 도메인에 대해 파일과 디렉터리를 복원할 수 있는 권한이 있어야 합니다. 특히 이 권한은 템플릿 및 기타 디렉터리 개체의 보안 설명자를 병합하여 도메인 PKI 개체에 올바른 권한을 부여하는 데 필요합니다. 기본 제공 도메인 그룹 Administrators, Server Operators 및 Backup Operators에는 기본적으로 이 권한이 있습니다. CA를 설치하는 데에는 Enterprise PKI Admins 그룹이 사용되므로 파일 및 디렉터리에 대한 복원 사용자 권한은 이 그룹에 부여되어야 합니다. **Enterprise PKI Admins에 복원 권한을 부여하려면** 1. 발행 CA가 설치될 도메인 내의 Domain Admins 구성원으로 로그온합니다. 2. Active Directory 사용자 및 컴퓨터 MMC 스냅인을 엽니다. 3. 도메인 컨트롤러 OU를 선택하고 해당 OU의 속성을 엽니다. 4. **그룹 정책** 탭에서 **기본 도메인 컨트롤러 정책 GPO**를 선택하고 **편집**을 클릭합니다. 5. 컴퓨터 구성\\Windows 설정\\보안 설정\\로컬 정책\\사용자 권한 할당으로 이동하고 **파일 및 디렉터리 복원**을 두 번 클릭합니다. 6. Enterprise PKI Admins 그룹을 표시된 목록에 추가합니다. 7. 대화 상자와 GPO 편집 MMC를 닫습니다. **참고**   도메인 컨트롤러에 파일 및 디렉터리 복원 사용자 권한을 설정한 다른 GPO가 있는 경우 기본 도메인 컨트롤러 정책이 아닌 최상위 우선 순위를 가진 GPO에서 이 절차를 수행해야 합니다. 사용자 권한 설정은 누적되지 않으며 이 권한 설정이 마지막으로 적용된 GPO만 유효합니다. ###### 루트 CA(인증 기관) 서버에 배포 앞에서 언급한 것과 같이, 대부분의 기업이 이미 문서화된 서버 구축 프로세스를 가지고 있기 때문에 이 가이드에서는 Windows Server 2003 설치를 위한 단계별 지침을 제공하지 않습니다. 그러나 루트 CA 서버는 손상을 방지하기 위해 네트워크에 연결되지 않는다는 점에서 다른 서버와 약간 다릅니다. 따라서 구축 프로세스를 진행하는 동안 루트 CA 서버가 네트워크에 연결되지 않도록 하고 우발적인 연결이 발생하지 않도록 일정 시점에서 네트워크 어댑터를 해제하도록 해야 합니다. 또한 이 서버는 네트워크에 연결되지 않고 작업 그룹에 상주하게 되므로 설치 전에 작업 그룹 이름을 선택하여 문서화해 놓는 것이 중요합니다. **참고**   루트 CA는 오프라인에서 구축되고 유지되지만 해당 이름은 네트워크 환경 내에서 고유해야 합니다. CAPolicy.inf 파일 루트 CA 서버로 사용할 서버 하드웨어를 준비하여 운영 체제를 설치한 후에는 capolicy.inf 파일을 만들어야 합니다. capolicy.inf 파일은 자체 서명한 루트 CA 인증서의 특성(예: 키 길이, 인증서 유효 기간 등)을 지정하므로 루트 CA를 만드는 데 반드시 필요합니다. CRL 및 AIA 정보는 루트 CA 인증서에 필요하지 않으므로 CRLDistributionPoint 및 AuthorityInformationAccess 매개 변수는 capolicy.inf 파일에서 Empty로 설정됩니다. **CAPolicy.inf 파일을 만들려면** 1. 메모장과 같은 텍스트 편집기를 사용하여 다음 텍스트가 들어 있는 일반 텍스트 파일을 만듭니다. ``` \[version\] Signature=”$Windows NT$” \[Certsrv\_server\] RednewalKeyLength=4096 RenewalValidityPeriod=Years RenewalValidityPeriodUnits=16 \[CRLDistributionPoint\] Empty=true \[AuthorityInformationAccess\] Empty=true ``` 2. 이 CA에 대해 특정 CPS가 정의된 경우, capolicy.inf 파일에 다음 내용을 추가하고 기울임꼴로 표시된 값을 이 구현에 해당하는 특정 값으로 바꿉니다. ``` \[CAPolicy\] Policies=company CPS name \[company CPS name\] OID=the.company.OID URL=”https://www.companyurl.com/cpspagename.htm” ``` 3. 이 텍스트 파일을 %windir%\\Capolicy.inf(%windir%은 C:\\Windows와 같이 Windows가 설치된 절대 경로로 대체)로 저장합니다. 이 파일을 Windows 폴더에 저장하고 이 단계를 완료하려면 관리자 계정 또는 이에 상응하는 권한을 가진 계정을 사용해야 합니다. 인증서 서비스 소프트웨어 구성 요소 설치 Windows 구성 요소 마법사를 사용하여 CA 소프트웨어 구성 요소를 설치합니다. 이 설치를 완료하려면 Windows Server 2003 설치 미디어에 액세스할 수 있어야 합니다. **인증서 서비스를 설치하려면** 1. 로컬 Administrators 그룹의 구성원으로 로그온한 다음 추가 구성 요소 관리자 또는 제어판에서 프로그램 추가/제거/Windows 구성 요소를 실행합니다. ``` sysocmgr /i:sysoc.inf ``` 2. 인증서 서비스 구성 요소를 선택합니다(**예**를 클릭하여 이름 바꾸기 경고 메시지 상자를 닫음). 3. CA 종류를 **독립 실행형 루트 CA**로 선택하고 **사용자 지정 설정 사용** 확인란이 선택되어 있는지 확인합니다. 4. **공개 및 개인 키 쌍** 대화 상자에서 다른 기본값 설정은 그대로 두고 **키 길이** 필드의 값을 **4096**로, **CSP 종류**를 **Microsoft Strong Cryptographic Provider**로 설정합니다. 5. 다음 필드에 대해 이전 단계에서 수집한 인증 기관 확인 정보를 입력합니다. - CA 공통 이름: - 고유 이름 접미사: - 유효 기간: 8년 이때 CSP는 키 쌍을 생성하고 로컬 컴퓨터 키 저장소에 이를 기록합니다. **참고**   이전에 이 시스템에 CA를 설치한 경우 이전에 설치한 개인 키를 덮어쓸 것인지를 묻는 대화 상자가 표시됩니다. 계속하기 전에 이 키가 더 이상 사용되지 않는지 확인하십시오. 6. 인증서 데이터베이스, 데이터베이스 로그 및 구성 폴더의 위치는 기본값 설정을 유지합니다. 이 시점에서 추가 구성 요소 관리자가 인증서 서비스 구성 요소를 설치하며 Windows Server 2003 설치 미디어가 사용됩니다. 7. **확인**을 클릭하여 IIS와 관련된 경고 메시지를 닫고 설치가 완료될 때까지 계속합니다. 루트 CA 속성 구성 이 섹션에 설명된 루트 CA를 구성할 때는 여러 환경 특정 매개 변수가 사용됩니다. 계속 진행하기 전에 이 가이드의 필수 정보 섹션에 나와 있는 설명대로 이러한 매개 변수를 수집해야 합니다. **루트 CA 속성을 구성하려면** 1. 로컬 관리자 그룹의 구성원으로 CA 서버에 로그온합니다. 2. C:\\MSSScripts\\pkiparams.vbs 스크립트를 다음과 같이 사용자 지정합니다. - AD\_ROOT\_DN의 설정값이 Active Directory 포리스트 루트 도메인 DN과 일치하도록 변경합니다. - HTTP\_PKI\_VROOT 설정이 앞에서 설정한 IIS 가상 디렉터리의 HTTP 경로와 일치하도록 변경합니다. 3. 다음 스크립트를 실행합니다. ``` Cscript //job:RootCAConfig C:\\MSSScripts\\ca\_setup.wsf ``` 관리 역할 구성 앞에서 만든 보안 그룹은 사용될 관리 역할(예: 감사자 및 인증서 관리자)에 매핑되어야 합니다. **참고**   대부분의 중소 기업에서는 앞에서 언급한 것과 같이 단순한 위임 모델을 사용하지만 더 세분화해야 할 경우를 고려하여 여기서는 보다 유연성 있는 모델을 설명합니다. **루트 CA 관리 역할을 구성하려면** 1. 인증 기관 관리 콘솔에서 **속성**을 클릭합니다. 2. **보안** 탭을 클릭하고 다음 표에 나열된 로컬 보안 그룹을 추가한 다음 각각의 사용 권한을 추가합니다. **표 13. CA 권한 항목**
그룹 사용 권한 허용/거부
CA Admins CA 관리 허용
Certificate Managers 인증서 발행 및 관리 허용
3. 이 서버의 다른 CA 보안 역할은 앞에서 적용한 보안 정책을 통해 이미 정의되어 있습니다. 루트 CA 인증서 및 CRL을 디스크에 전송 루트 CA 인증서 및 CRL은 Active Directory 및 IIS 인증서 및 CRL 게시 서버에 게시할 수 있도록 CA에서 복사해야 합니다. 이 예에서는 디스크를 사용했지만 USB 드라이브를 포함한 모든 휴대용 미디어를 사용할 수 있습니다. **루트 CA 인증서 및 CRL을 디스크에 복사하려면** 1. 로컬 CA Admins 그룹의 구성원으로 루트 CA에 로그온하고 휴대용 미디어를 서버에 집어넣습니다. 2. 다음 스크립트를 실행하여 CA 인증서를 디스크에 복사합니다. ``` Cscript //job:GetCACerts C:\\MSSScripts\\CA\_Operations.wsf ``` 3. 다음 스크립트를 실행하여 CA CRL을 디스크에 복사합니다. ``` Cscript //job:GetCRLs C:\\MSSScripts\\CA\_Operations.wsf ``` 4. 나중에 사용할 수 있도록 이 디스크에 레이블을 표시하고 날짜를 기록한 후 보관하십시오. ###### 루트 CA 정보 게시 발행 CA를 설치하기 전에 루트 CA의 인증서를 Active Directory의 신뢰할 수 있는 루트 저장소에, 루트 CRL을 Active Directory CDP 컨테이너에 게시해야 합니다. 이 프로세스를 통해 모든 도메인 구성원은 루트 CA의 인증서를 각자의 신뢰할 수 있는 루트 저장소로 가져와 루트 CA에서 발행한 모든 인증서의 해지 상태를 확인할 수 있습니다. 발행 CA에는 필요한 Certutil.exe, certadm.dll 및 certcli.dll 라이브러리가 설치되어 있기 때문에 이 절차는 발행 CA를 사용하여 수행하는 것이 좋습니다. 그러나 certutil.exe와 지원하는 DLL 파일이 Windows Server 2003 기반 시스템에 설치되어 있는 경우에는 구성원 서버를 사용할 수도 있습니다. **루트 CA 인증서 및 CRL을 Active Directory에 게시하려면** 1. 이전에 설명한 요구 사항을 충족하는 도메인 구성원 컴퓨터에 Enterprise PKI Admins 그룹의 구성원으로 로그온하고 루트 CA 인증서 및 CRL을 저장하기 위해 만든 디스크를 삽입합니다. 2. 다음 스크립트를 실행하여 CA 인증서를 Active Directory에 게시합니다. ``` Cscript //job:PublishCertstoAD C:\\MSSScripts\\CA\_Operations.wsf ``` 3. 다음 스크립트를 실행하여 CRL을 Active Directory에 게시합니다. ``` Cscript //job:PublishCRLstoAD C:\\MSSScript\\CA\_Operations.wsf ``` 루트 CA 인증서 및 CRL을 웹 서버에 게시 이 작업은 CDP와 AIA URL의 HTTP 버전이 이 CA에서 발행한 인증서 확장에 지정되었기 때문에 필요합니다. 이러한 확장이 있는 경우 CRL과 인증서를 인증서에 구성된 URL에 게시해야 합니다. **참고**   이 절차는 CDP와 AIA 게시 웹 서버가 발행 CA에 있는지 여부에 영향을 받지 않습니다. 그러나 가상 디렉터리가 IIS를 구성하는 앞의 절차에서 설정한 디렉터리(C:\\CAWWWPub)와 일치한다고 가정합니다. 다른 경로가 선택되었다면 PKIParams.vbs 스크립트의 WWW\_LOCAL\_PUB\_PATH 값을 수정해야 합니다. **루트 CA 인증서 및 CRL을 웹 URL에 게시하려면** 1. 로컬 관리자 또는 이에 상응하는 계정으로 웹 서버에 로그온합니다. 2. 루트 CA 인증서 및 CRL 디스크가 삽입되었는지 확인합니다. 3. 다음 스크립트를 실행하여 CA 인증서를 웹 서버 폴더에 게시합니다. ``` Cscript //job:PublishRootCerttoIIS C:\\MSSScripts\\CA\_Operations.wsf ``` 4. 다음 스크립트를 실행하여 CA CRL을 웹 서버 폴더에 게시합니다. ``` Cscript //job:PublishRootCRLstoIIS C:\\MSSScripts\\CA\_Operations.wsf ``` ###### 발행 CA 서버 배포 루트 CA가 설치되었고 해당 인증서가 게시되었으므로 이제 발행 CA 서버를 배포할 수 있습니다. 인증서 서비스를 설치하려면 발행 CA, 루트 CA, Active Directory 및 웹 서버 간에 복잡한 상호 작용이 이루어져야 합니다. 이러한 상호 작용은 다음 도표를 참조하면 쉽게 이해할 수 있습니다. [![](images/Cc875845.SWCG5(ko-kr,TechNet.10).gif)](https://technet.microsoft.com/ko-kr/cc875845.swcg5_big(ko-kr,technet.10).gif) **그림 5. 인증서 설치 프로세스** 도표에서 번호가 표시된 상호 작용의 내용을 설명하면 다음과 같습니다. 1. 이동식 미디어를 사용하여 루트 CA 인증서 및 CRL을 Active Directory에 게시합니다. 2. 이동식 미디어를 사용하여 루트 CA 인증서 및 CRL을 웹 서버에 게시합니다. 3. 인증서 요청을 생성하는 인증서 서비스 소프트웨어를 설치합니다. 이 인증서 요청은 이동식 미디어를 통해 루트 CA에 전달되고 이 요청을 기반으로 인증서가 발행됩니다. 4. 이동식 미디어를 사용하여 해당하는 발행 CA 인증서를 설치합니다. 5. 발행 CA 인증서 및 CRL을 웹 서버에 게시합니다.     x.   이 단계는 엔터프라이즈 CA 설치 루틴 중에 자동으로 발생합니다. 발행 CA를 위해 Capolicy.inf 파일 준비 CAPolicy.inf는 원래 발행 CA에 필요하지 않지만 CA에서 사용되는 키 크기를 변경하려는 경우에는 필요합니다. 이 파일은 필요한 경우 나중에 추가하여 CA 인증서를 갱신할 수도 있지만 발행 CA를 설치하기 전에 작성되어야 합니다. **CAPolicy.inf 파일을 만들려면** 1. 로컬 관리자 계정 또는 이에 상응하는 계정으로 발행 CA 서버에 로그온합니다. 2. 메모장과 같은 텍스트 편집기를 사용하여 다음 정보를 포함하는 일반 텍스트 파일을 만듭니다. ``` \[Version\] Signature= “$Windows NT$” \[Certsrv\_Server\] RenewalKeyLength=2048 ``` 3. 이 CA에 대해 CPS가 정의되어 있으면 Capolicy.inf 파일에 다음 줄을 추가합니다. ``` \[CAPolicy\] Policies=policyname \[policyname\] OID=the.org.oid URL=”https://the.org.url/TheCPSPage.htm” ``` **참고**   기울임꼴로 표시된 항목은 조직 설정에 맞는 정보로 대체해야 합니다. 4. 이 파일을 %windir%\\Capolicy.inf(%windir%은 C:\\Windows와 같이 Windows 설치 폴더의 절대 경로로 대체)로 저장합니다. 인증서 서비스 소프트웨어 구성 요소 설치 루트 CA에서 인증서 서비스를 설치할 때와 마찬가지로, 이 설치 단계에도 Windows 구성 요소 마법사와 함께 Windows Server 2003 설치 미디어가 필요합니다. **인증서 서비스를 설치하려면** 1. 로컬 Administrators 그룹의 구성원 또는 이에 상응하는 계정으로 발행 CA에 로그온하고 추가 구성 요소 관리자를 실행합니다. ``` sysocmgr /i:sysoc.inf ``` 2. 인증서 서비스 구성 요소를 선택하고 **확인**을 클릭하여 이름 바꾸기 경고 메시지 상자를 닫습니다. 3. CA 종류를 엔터프라이즈 하위 CA로 선택하고 **사용자 지정 설정 사용** 확인란이 선택되어 있는지 확인합니다. 4. **공개 및 개인 키 쌍** 대화 상자에서 기본값 설정을 그대로 유지합니다. 단, 다음은 예외입니다. - 키 길이 – 2048비트 - CSP 종류 – Microsoft Strong Cryptographic Provider 5. 다음과 같은 CA 확인 정보를 입력합니다. - CA 공통 이름 - 고유 이름 접미사 - 유효 기간: (상위 CA에서 결정한 대로 지정) 6. 이때 CSP는 키 쌍을 생성하고 로컬 컴퓨터 키 저장소에 이를 기록합니다. 7. 다음에 제안된 대로 인증서 데이터베이스, 데이터베이스 로그 및 구성 폴더의 위치를 입력합니다. - 인증서 데이터베이스: D:\\CertLog - 인증서 데이터베이스 로그: %windir%\\System32\\CertLog - 공유 폴더: 사용 안 함 성능 및 복원력에 영향을 줄 수 있기 때문에 가능하면 CA 데이터베이스와 로그를 별개의 볼륨에 저장해야 합니다. 또한 인증서 데이터베이스 및 데이터베이스 로그는 모두 NTFS로 포맷된 로컬 드라이브에 있어야 합니다. 8. 이제 디스크로 복사해야 하는 인증서 요청 파일이 생성되고 추가 구성 요소 관리자가 인증서 서비스 구성 요소를 설치합니다. 이를 위해 Windows Server 2003 설치 미디어에 액세스해야 합니다. 9. **확인**을 클릭하여 IIS에 대한 경고 메시지를 닫고 설치를 계속해 완료합니다. 계속하려면 상위 CA의 인증서가 필요하다는 설치 마법사의 알림이 표시됩니다. 루트 CA에 인증서 요청 제출 이제 발행 CA 인증서 요청을 루트 CA로 보내 요청에 서명하고 발행 CA에 인증서를 발행해야 합니다. **루트 CA에 인증서 요청을 제출하려면** 1. 인증서 관리자 그룹 구성원 계정으로 루트 CA에 로그온합니다. 2. 인증서 요청 파일을 저장하는 데 사용할 디스크가 드라이브에 있는지 확인합니다. 3. 인증 기관 관리 콘솔의 **CA 작업** 메뉴에서 **새 요청 제출**을 선택한 다음 발행 CA로부터 전송된 요청을 제출합니다. 4. 발행된 인증서 컨테이너에서 새로 발행된 인증서를 찾아서 엽니다. 5. 인증서 정보가 올바른지 확인한 후 파일에 복사를 클릭하여 인증서를 파일로 내보냅니다. 이 파일을 디스크에 PKCS\#7 파일로 저장하고 체인에서 가능한 모든 인증서를 포함하는 옵션을 선택합니다. 발행 CA에서 인증서 정보 새로 고침 루트 CA 인증서가 이미 Active Directory의 신뢰할 수 있는 루트 저장소에 게시되었으므로, 이제 발행 CA에서 이 정보를 다운로드했고 인증서를 해당 루트 저장소에 저장했는지 확인해야 합니다. **발행 CA에서 인증서 신뢰 정보를 새로 고치고 확인하려면** 1. 로컬 관리자 또는 이에 상응하는 계정으로 발행 CA에 로그온합니다. 2. 명령 프롬프트에서 다음을 실행합니다. ``` certutil –pulse ``` 이 명령은 CA가 신뢰할 수 있는 새로운 루트 정보를 디렉터리에서 다운로드하고 루트 CA 인증서를 신뢰할 수 있는 해당 루트 저장소에 저장하도록 합니다. 이 단계가 반드시 필요하지는 않지만 계속하기 전에 앞의 게시 단계가 성공적이었는지 확인하는 역할을 합니다. 3. mmc.exe를 실행하고 인증서 스냅인을 추가합니다. 4. 관리할 인증서 저장소로 **컴퓨터 계정**을 선택합니다. 5. 루트 CA 인증서가 신뢰할 수 있는 루트 CA 폴더에 있는지 확인합니다. 발행 CA에서 인증서 설치 루트 CA로부터의 서명된 응답이 PKCS\#7 인증서 패키지로 만들어졌으므로 이제 발행 CA에서 설치할 수 있습니다. CA 인증서를 Active Directory NTAuth 저장소에 게시하려면(이 저장소는 CA를 엔터프라이즈 CA로 식별) 발행 CA에서 Enterprise PKI Admins 그룹과 로컬 Administrators 그룹 모두의 구성원인 계정을 사용하여 CA 인증서를 설치해야 합니다. 전자 그룹에는 CA 인증서를 디렉터리에 설치하는 권한이 있고 후자 그룹에는 인증서를 CA 서버에 설치하는 권한이 있습니다. 앞에서 언급한 단순한 관리 모델이 사용되는 경우에는 이미 CAAdmin 역할이 두 그룹의 구성원이 됩니다. **발행 CA 인증서를 설치하려면** 1. Enterprise PKI Admins 그룹과 로컬 Administrators 그룹 모두의 구성원인 계정을 사용하여 발행 CA에 로그온합니다. 2. 루트 CA에서 발행한 서명된 인증서가 들어 있는 디스크를 집어넣습니다. 3. 인증 기관 관리 콘솔의 **CA 작업** 메뉴에서 **인증서 설치**를 선택하여 디스크에서 발행 CA 인증서를 설치합니다. 그러면 CA가 시작됩니다. 발행 CA 속성 구성 다음 절차는 발행 CA의 이전 필수 단계에서 수집된 특정 환경 매개 변수를 구성합니다. 이 단계를 계속하기 전에 이전 필수 단계에서 수집된 조직 특정 정보가 루트 CA의 C:\\MSSScripts\\pkiparams.vbs 파일에 삽입되었는지, 그리고 이러한 변경 내용이 발행 CA에도 전송되었는지 확인해야 합니다. **발행 CA 속성을 구성하려면** 1. 로컬 Administrators 그룹의 구성원으로 발행 CA 서버에 로그온합니다. 2. C:\\MSSScripts\\pkiparams.vbs에서 변경한 내용이 이 섹션의 앞 부분에서 설명한 특정 환경 설정과 일치하는지 확인합니다. 3. 다음 스크립트를 실행합니다. ``` Cscript //job:IssCAConfig C:\\MSSScripts\\ca\_setup.wsf ``` 발행 CA 관리 역할 구성 이 가이드에서 설명하는 관리 역할을 사용하려면 해당 역할을 보안 그룹에 매핑시켜야 합니다. 앞에서 설명한 바와 같이, 대부분의 중소 기업에서는 단순한 역할 모델로도 충분하지만 이 프로세스에서는 유연성과 책임 분담을 극대화하도록 디자인된 세부적인 역할 모델을 구현합니다. **발행 CA에서 역할을 구성하려면** 1. 로컬 Administrators 그룹의 구성원으로 발행 CA 서버에 로그온합니다. 2. 인증 기관 관리 콘솔에서 속성을 클릭하고 CA의 속성을 편집합니다. 3. **보안** 탭을 클릭하고 다음 표에 나열된 도메인 보안 그룹을 추가한 다음 표시된 것처럼 각각의 사용 권한을 추가합니다. **표 14. 발행 CA 사용 권한**
그룹 사용 권한 허용/거부
CA Admins CA 관리 허용
Certificate Managers 인증서 발행 및 관리 허용
4. CA Auditors 그룹은 앞에서 적용된 보안 정책을 통해 이미 부분적으로 정의되어 있지만 로컬 Administrators 그룹에 추가해야 합니다. ###### 발행 CA 정보 게시 Active Directory에는 발행 CA의 인증서 및 CRL이 자동으로 게시되지만 HTTP CDP 및 AIA 경로 게시의 경우에는 그렇지 않습니다. HTTP CDP 및 AIA 경로에 CA 인증서가 자동으로 게시되게 하려면 예약된 작업을 설정해야 합니다. CA 인증서는 아주 가끔씩만 업데이트되므로 다음 프로세스를 사용하여 AIA에 수동으로 게시할 수 있습니다. **발행 CA 인증서를 게시하려면** 1. 게시된 웹 서버 폴더에 대한 쓰기 권한을 가진 계정으로 발행 CA에 로그온합니다. 2. 웹 서버 폴더의 대상 경로와 일치하도록 C:\\MSSScripts\\PKIParams.vbs의 WWW\_REMOTE\_PUB\_PATH 매개 변수를 업데이트합니다. 1. 웹 서버가 원격 서버에 있는 경우에는 웹 서버 폴더를 공유하고 이 공유 폴더의 해당 UNC 경로를 기록해야 합니다. 2. 웹 서버가 CA와 동일한 서버에 있는 경우에는 해당 폴더의 로컬 경로를 기록합니다(기본값은 로컬 경로 C:\\CAWWWPub임). 3. 다음 스크립트를 실행하여 CA 인증서를 웹 서버에 게시합니다. ``` Cscript //job:PublishIssCertsToIIS C:\\MSSScripts\\CA\_Operations.wsf ``` **참고**   이 절차는 내부 웹 서버의 경우를 전제한 것입니다. 인증서가 인터넷에 연결된 웹 서버에 게시되는 경우 보통 인터넷 방화벽에 의해 차단되는 Windows 네트워크 파일 공유에 이 솔루션이 영향을 받을 수 있으므로 추가적인 단계를 수행해야 합니다. CRL은 CA 인증서보다 자주 게시되므로 자동화된 방법으로 웹 서버에 CRL을 게시해야 합니다. **CRL 게시를 자동화하려면** 1. 로컬 Administrators의 구성원인 계정으로 발행 CA에 로그온합니다. 2. 이 서버에서 웹 서버 폴더에 액세스할 수 있는지 확인합니다. 3. 웹 서버가 원격인 경우에는 발행 CA에 파일 시스템 폴더(수정 권한) 및 공유(변경 권한)에 대한 쓰기 권한이 필요합니다. 웹 서버가 포리스트의 구성원이면 도메인 Cert Publishers 그룹을 사용하여 모든 엔터프라이즈 CA가 인증서 및 CRL을 게시할 수 있는 액세스 권한을 부여할 수 있습니다. 4. 다음 명령을 실행하여 CRL을 복사하는 예약된 작업을 만듭니다. **참고**   다음 코드 조각의 일부는 가독성을 고려하여 여러 줄로 표시되어 있습니다. 이 내용은 한 줄에 입력해야 합니다. ``` schtasks /creat /tn “Publish CRLs” /tr “cscript.exe //job:PublishIssCRLsToIIS C:\\ MSSScripts\\CA\_Operations.wsf” /sc Hourly /ru “System” ``` 원하지 않는 발행 CA 템플릿 제거 사용되지 않는 인증서가 실수로 발행되지 않도록 해당 인증서 종류의 템플릿을 제거하는 것이 좋습니다. 이러한 템플릿은 항상 디렉터리에서 사용할 수 있기 때문에 필요한 경우 쉽게 다시 만들 수 있습니다. **발행 CA에서 원하지 않는 템플릿을 제거하려면** 1. CA Admins 도메인 그룹의 구성원으로 로그온합니다. 2. 인증 기관 관리 콘솔에서 인증서 템플릿 컨테이너를 선택합니다. 3. 다음 템플릿 종류를 제거합니다. - EFS 복구 에이전트 - 기본 EFS - 웹 서버 - 컴퓨터 - 사용자 - 종속 인증 기관 - 관리자 ##### 인터넷 인증 이 섹션에서는 이 가이드에서 제공하는 보안 WLAN 솔루션을 지원하기 위한 RADIUS 인프라의 구현을 돕는 자세한 정보를 제공합니다. 이 가이드에서 구현되는 RADIUS 인프라는 Windows Server 2003 인터넷 인증 서버(IAS)를 기반으로 합니다. ###### RADIUS 인프라 디자인 다음 표들은 이 가이드의 전반에 걸쳐 참조되는 필수 정보를 수집하는 워크시트로 사용할 수 있습니다. 이 정보의 일부는 이 가이드와 함께 제공되는 스크립트를 사용하여 설정되었거나 해당하는 섹션에 나열된 내용으로 구성된 것입니다. 사용자 정의된 필수 구성 정보 다음 표는 각 조직 고유의 정보를 나열합니다. 계속 진행하기 전에 해당 정보를 수집하고, 결정하고, 기록했는지 확인하십시오. **표 15. 사용자 정의된 구성 설정**

구성 항목 설정
Active Directory 포리스트 루트 도메인의 DNS 이름  
도메인의 NetBIOS 이름  
주 IAS 서버 이름  
보조 IAS 서버 이름  
##### 솔루션에 정의된 필수 구성 정보 다음 표에는 특정한 요구가 있는 경우가 아니면 변경할 필요가 없는 설정이 나와 있습니다. 스크립트 변경을 포함하여 여기에 나열된 매개 변수를 변경하려면 먼저 이러한 내용을 변경함으로써 발생할 수 있는 모든 영향 및 종속성을 완전하게 이해하고 계획해야 합니다. **표 16. 솔루션에 정의된 구성 설정**

구성 항목 설정
IAS 구성을 제어하는 관리 그룹의 전체 이름 IAS Admins
IAS 인증 및 계정 요청 로그를 검토하는 그룹의 전체 이름 IAS Security Auditors
설치 스크립트 경로 C:\MSSScripts
IAS 구성 내보내기 배치 파일 IASExport.bat
IAS 구성 가져오기 배치 파일 IASImport.bat
IAS RADIUS 클라이언트 구성 내보내기 배치 파일 IASClientExport.bat
IAS RADIUS 클라이언트 구성 가져오기 배치 파일 IASClientImport.bat
구성 백업 파일의 경로 D:\IASConfig
IAS 인증 및 감사 요청 로그의 위치 D:\IASLogs
RADIUS 요청 로그의 공유 이름 IASLogs
###### IAS 서버 배포 다음 섹션에서 설명하는 솔루션에는 WLAN 액세스 제어를 위해 RADIUS 서버로 중앙에 구성된 두 대의 IAS 서버가 포함됩니다. 이 점을 염두에 두고, 계속 진행하기 전에 다음 작업을 완료해야 합니다. - 서버 하드웨어를 할당하고 구성해야 합니다. - 정해진 조직의 절차에 따라 서버 운영 체제를 설치하고 구성해야 합니다. - Active Directory가 정상적으로 작동해야 합니다. - 조직의 서버 강화 절차 및 설정된 정책에 필요한 추가 응용 프로그램이 갖추어져 있어야 합니다. 구성 스크립트 설치 이 솔루션의 구현을 도울 수 있도록 여러 지원 스크립트가 제공됩니다. 각 서버에 이 스크립트를 설치해야 하며 이 가이드에 설명된 절차를 완료한 이후에도 삭제해서는 안 됩니다. **설치 스크립트를 설치하려면** 1. C:\\MSSScripts 폴더를 만듭니다. 2. 배포 소스의 스크립트를 복사하여 위에서 만든 폴더에 붙여 넣습니다. 서버 소프트웨어 추가 요구 사항 설정된 서버 구축 정책에 필요한 서버 운영 체제 및 기타 응용 프로그램 외에도, 이 가이드에서 제공하는 스크립트를 지원하려면 CAPICOM 2.1 실행 파일 및 지원 DLL 라이브러리를 설치해야 합니다. 다운로드 위치 및 설치 지침을 포함한 [CAPICOM](https://www.microsoft.com/download/details.aspx?familyid=860ee43a-a843-462f-abb5-ff88ea5896f6&displaylang=ko)에 대한 자세한 내용은 www.microsoft.com/downloads/details.aspx?FamilyID=860ee43a-a843-462f-abb5-ff88ea5896f6&DisplayLang=ko를 참조하십시오. IAS 관리 그룹 구성 다음 스크립트 명령을 실행하면 IAS Admins 및 IAS Security Auditors 보안 그룹이 만들어집니다. ``` Cscript //job:CreateIASGroups C:\\MSSScripts\\IAS\_Tools.wsf ``` 다중 도메인 환경에서는 IAS 서버가 있는 도메인에 이 그룹을 만들어야 합니다. 필요한 그룹을 만든 후에는 다음을 수행하여 IAS 구성 작업을 수행할 수 있도록 해당 그룹을 구성해야 합니다. - IAS Admins 도메인 글로벌 그룹을 각 IAS 서버의 로컬 Administrators 그룹에 추가합니다. - IAS가 도메인 컨트롤러에 설치된 경우에는 해당 도메인의 Administrators 그룹에 IAS Admins 그룹을 추가해야 합니다. - IAS Admins 및 IAS Security Auditors 그룹을 해당하는 사용자 계정으로 채워야 합니다. 서버 시스템 보안 설정 구성 앞에서 언급한 바와 같이, 이 가이드에서는 대부분의 중소 기업이 적절한 서버 강화 절차 및 정책을 수립했다고 가정합니다. 따라서 이 가이드에서는 이 솔루션에 필요한 서버를 보호하는 프로세스에 대한 자세한 지침을 제공하지 않습니다. 서버 강화에 대한 정책 또는 절차가 수립되지 않았거나 IAS 서버 보호에 대한 자세한 내용을 보려면 [Windows 2003 Security Guide (영문)](https://go.microsoft.com/fwlink/?linkid=14846)(https://go.microsoft.com/fwlink/?LinkId=14846)를 참조하십시오. ###### IAS 설치 및 구성 다음 섹션에서는 서버에 IAS를 설치하는 방법에 대해 설명합니다. 여기서는 각 설치 및 구성 단계를 나열된 순서에 따라 각 IAS 서버에 수행하는 것이 중요합니다. IAS는 제어판의 구성 요소 추가/제거를 통해 Windows 추가 구성 요소 관리자에 액세스한 후 네트워킹 서비스 - 인터넷 인증 서비스를 선택하여 설치합니다. 이 프로세스를 단순화하려면 다음 스크립트를 사용하십시오. ``` sysocmgr /i:sysoc.inf /u:C:\\MSSScripts\\OC\_AddIAS.txt ``` Active Directory에 IAS 등록 IAS 서버는 IAS 서버 각각의 컴퓨터 계정을 인증에 필요한 각 도메인 내의 RAS 및 IAS 서버 보안 그룹의 구성원으로 만들어 해당 도메인에 등록해야 합니다. 이 그룹의 구성원은 IAS 서버가 도메인 내의 모든 사용자 및 컴퓨터 계정의 원격 액세스 속성을 읽을 수 있는 권한을 갖도록 합니다. **Active Directory에 IAS를 등록하려면** 1. IAS 서버를 등록할 도메인에 대해 Domain Admin 권한을 가진 계정으로 각 서버에 로그온합니다. 2. 기본 도메인의 경우에는 명령 프롬프트에서 다음을 실행합니다. ``` netsh ras add registeredserver ``` 3. 기본 도메인 이외의 도메인인 경우에는 명령 프롬프트에서 다음을 실행합니다. ``` netsh ras add registeredserver domain = DomainName ``` **참고**   Active Directory 사용자 및 컴퓨터 MMC 스냅인을 통해 IAS 서버 컴퓨터 개체를 RAS 및 IAS 서버 보안 그룹에 추가할 수도 있습니다. IAS 데이터 디렉터리 만들기 및 보안 유지 구성 및 로그 데이터를 IAS 서버에 저장하기 위한 몇 가지 디렉터리 요구 사항이 있습니다. 이러한 디렉터리를 만들고 보호하는 구성 프로세스를 단순화하려면 명령 프롬프트에서 다음 배치 파일을 사용하면 됩니다. ``` C:\\MSSScripts\\IAS\_Data.bat ``` **참고**   이 배치 파일을 실행하기 전에 특정 환경의 NETBIOS 도메인 이름이 반영되도록 이 배치 파일의 %DomainName% 항목을 편집하거나 바꿔야 할 수 있습니다. ###### 주 IAS 서버 구성 주 IAS 서버로 작동하도록 선택된 서버는 모든 후속 IAS 서버의 설정을 구성하는 템플릿 역할을 하기 때문에 환경 내의 다른 IAS 서버보다 먼저 구성해야 합니다. 인증 및 계정 요청 로깅 IAS에서는 기본적으로 RADIUS 인증 및 계정 요청을 로깅하지만 보안 이벤트를 기록하여 조사가 필요할 때 사용할 수 있도록 이 두 요청을 모두 사용하도록 설정해야 합니다. **인증 및 계정 요청 로깅을 구성하려면** 1. 인터넷 인증 서비스 MMC 스냅인에서 원격 액세스 로깅을 선택하고 로컬 파일 로깅 방법의 속성을 확인합니다. 2. 계정 요청 및 인증 요청을 선택합니다. 3. 로그 파일 디렉터리가 D:\\IASLogs로 설정되어 있으며 데이터베이스 호환 가능 형식이 선택되어 있는지 확인합니다. (이렇게 하면 Microsoft SQL Server™와 같은 데이터베이스로 로그를 직접 가져올 수 있습니다.) ##### WLAN 802.1X 인증 이 섹션에서는 Windows Server 2003 및 Windows XP SP1 플랫폼을 기반으로 802.1X 프로토콜 규격을 사용하여 WLAN 보안을 구현하는 프로세스 단계를 설명합니다. 여기에는 Active Directory 그룹 구성, X.509 인증서 배포, IAS 서버 설정 수정 및 WLAN 그룹 정책 배포에 대한 정보와 함께 802.1X EAP-TLS 구현을 지원하는 무선 액세스 지점을 구성하기 위한 몇 가지 팁이 포함됩니다. ###### 보안 WLAN을 위한 환경 준비 기본적인 인증서 및 RADIUS 인프라가 구축되었으므로 이제 실제적인 802.1X 특정 구성 단계를 구현할 수 있습니다. 다음 필수 설정 표는 실제 구현을 수행하기 전에 필요한 정보 수집 프로세스에 도움이 될 수 있습니다. 이러한 내용 중 일부는 수동으로 설정되며 다른 일부는 이 가이드에서 제공하는 스크립트에 포함되어 있습니다. 사용자 정의된 필수 구성 설정 다음 표에는 보안 WLAN 구현 단계를 진행하기 전에 수집 또는 결정해야 하는 조직 관련 매개 변수가 나열되어 있습니다. 제공된 공란은 각 특정 환경에 필요한 설정을 기록하는 데 사용할 수 있습니다. **표 17. 사용자 정의된 필수 설정**

구성 항목 설정
Active Directory 포리스트 루트 도메인 DNS 이름  
NetBIOS 도메인 이름  
주 IAS 서버 이름  
보조 IAS 서버 이름  
##### 솔루션에 정의된 필수 구성 설정 다음 표에는 특정한 요구가 있는 경우가 아니면 변경할 필요가 없는 설정이 나와 있습니다. 스크립트 변경을 포함하여 여기에 나열된 매개 변수를 변경하려면 먼저 이러한 내용을 변경함으로써 발생할 수 있는 모든 영향 및 종속성을 완전하게 이해하고 계획해야 합니다. **표 18. 솔루션에 정의된 구성 설정**

구성 항목 설정
802.1X 사용자 인증 인증서의 배포를 제어하는 Active Directory 글로벌 그룹 클라이언트 인증 - 사용자 인증서 자동 등록
802.1X 컴퓨터 인증 인증서의 배포를 제어하는 Active Directory 글로벌 그룹 클라이언트 인증 - 컴퓨터 인증서 자동 등록
802.1X 인증 인증서를 요청하는 IAS 서버가 포함된 Active Directory 글로벌 그룹 RAS 및 IAS 서버 인증 인증서 자동 등록
무선 네트워크에 액세스할 수 있는 사용자가 포함된 Active Directory 글로벌 그룹 원격 액세스 정책 - 무선 사용자
무선 네트워크에 액세스할 수 있는 컴퓨터가 포함된 Active Directory 글로벌 그룹 원격 액세스 정책 - 무선 컴퓨터
무선 사용자 그룹과 무선 컴퓨터 그룹이 모두 포함된 Active Directory 유니버설 그룹 원격 액세스 정책 - 무선 액세스
무선 네트워크 속성의 구성을 요청하는 컴퓨터가 포함된 Active Directory 글로벌 그룹 무선 네트워크 정책 - 컴퓨터
사용자 클라이언트 인증용 인증서를 생성하는 데 사용되는 인증서 템플릿 클라이언트 인증 - 사용자
컴퓨터 클라이언트 인증용 인증서를 생성하는 데 사용되는 인증서 템플릿 클라이언트 인증 - 컴퓨터
IAS용 서버 인증 인증서를 생성하는 데 사용되는 인증서 템플릿 RAS 및 IAS 서버 인증
설치 스크립트 경로 C:\MSSScripts
구성 백업 파일의 경로 D:\IASConfig
IAS 인증 및 감사 로그의 경로 D:\IASLogs
정책 이름 무선 액세스 허용
Active Directory GPO 이름 무선 네트워크 정책
상기 GPO 내의 무선 네트워크 정책 클라이언트 컴퓨터 무선 구성
##### WLAN 액세스를 위한 필수 Active Directory 그룹 만들기 다음 스크립트는 무선 인증 인증서 등록, 원격 액세스 정책 및 무선 네트워크 그룹 정책을 구현하는 데 필요한 필수 그룹을 만들기 때문에 Active Directory 보안 그룹을 만들 수 있는 권한을 가진 계정으로 실행해야 합니다. ``` Cscript //job:CreateWirelessGroups C:\\MSSScripts\\wl\_tools.wsf ``` **참고**   다중 도메인 포리스트 환경에서는 무선 사용자 도메인과 같은 도메인에 그룹을 만들어야 합니다. DHCP 설정 확인 무선 네트워크를 수용하려면 무선에 고유한 범위 및 유선 클라이언트보다 짧은 IP 주소 임대 시간으로 DHCP 서버를 구성해야 합니다. DHCP 서버 관리자와 함께 DHCP가 올바로 구성되었는지 확인하십시오. 무선 LAN을 위한 DHCP 계획 수립에 대한 자세한 내용은 [Windows Server 2003 Deployment Kit](https://www.microsoft.com/korea/windowsserver2003/techinfo/reskit/deploykit.mspx)(www.microsoft.com/korea/windowsserver2003/techinfo/reskit/deploykit.mspx)를 참조하십시오. ###### WLAN 인증 인증서 구성 EAP-TLS 기반 WLAN 보안을 이 가이드에서와 같이 세부적으로 구현하려면 다음과 같은 인증서 종류를 만들어 배포해야 합니다. - 클라이언트 인증 - 컴퓨터 - 클라이언트 인증 - 사용자 - RAS 및 IAS 서버 인증 IAS 서버 인증용 인증서 템플릿 만들기 IAS 서버에는 EAP-TLS 프로토콜 핸드셰이크 중에 클라이언트의 컴퓨터를 인증하는 서버 인증서가 필요합니다. IAS 서버에서 사용될 서버 인증 인증서 템플릿을 만들려면 인증서 서비스 관리자가 다음 단계를 수행해야 합니다. **서버 인증용 인증서 템플릿을 만들려면** 1. CA 관리 그룹 계정으로 발행 CA에 로그온하고 인증서 템플릿 MMC를 실행합니다. 2. RAS 및 IAS 서버 인증서 템플릿을 복제합니다. 새 템플릿 속성의 **일반** 탭에 있는 **템플릿 표시 이름** 필드에 **RAS 및 IAS 서버 인증**을 입력합니다. 3. **확장** 탭의 발급 정책에 서버 인증(OID 1.3.6.1.5.5.7.3.1)만 포함되어 있는지 확인합니다. 4. 또한 **확장** 탭에서 발급 정책을 편집하여 보통 보증 정책을 추가합니다. 5. **주체 이름** 탭에서 **이 Active Directory 정보로 만듦**을 선택합니다. **주체 이름 형식**이 **일반 이름**으로 설정되어 있고 **대체 주체 이름**의 **이 정보 포함**에서 **DNS 이름**만 선택되어 있는지도 확인합니다. 6. **요청 처리** 탭에서 **CSP** 단추를 클릭하고 **요청에서 다음 CSP 중 하나를 사용해야 함**이 선택되어 있는지, 그리고 **Microsoft RSA SChannel Cryptographic Provider**만 선택되어 있는지 확인합니다. 7. **보안** 탭에서 읽기, 등록 및 자동 등록 권한을 가진 **RAS 및 IAS 서버 인증 인증서 자동 등록** 보안 그룹을 추가하고 이 인증서 템플릿에 대한 등록 또는 자동 등록 권한을 가지고 있을 수 있는 다른 그룹을 모두 제거합니다. **참고**   이 인증서는 비교적 높은 보안 값을 가진 것으로 간주되기 때문에 인증서 관리자의 승인을 요청하도록 설정하는 것이 좋습니다. 이 값을 사용하면 악의적인 IAS 서버가 등록되지 않도록 할 수 있으며 인증서가 발행되고 IAS 서버가 자동으로 인증서를 보낸 후에도 수동 승인을 요청합니다. 사용자 인증용 인증서 템플릿 만들기 최종 사용자는 EAP-TLS 핸드셰이크 프로세스 중에 IAS 서버를 인증하는 사용자 인증서가 필요합니다. 인증서 서비스 관리자로 지정된 계정 소유자는 다음 단계를 다시 수행해야 합니다. **사용자 인증 인증서 템플릿을 만들려면** 1. 발행 CA 서버에서 인증서 템플릿 MMC 스냅인을 실행합니다. 2. 인증된 세션 템플릿을 복제하고 새 템플릿의 **일반** 탭에 있는 **템플릿 표시 이름** 필드에 **클라이언트 인증 - 사용자**를 입력합니다. 3. **요청 처리** 탭에서 **CSP**를 선택하고 **Microsoft Base DSS** **Cryptographic Provider** 확인란의 선택을 취소합니다. 4. **주체 이름** 탭에서 **이 Active Directory 정보로 만듦**이 선택되어 있는지 확인합니다. **주체 이름** 형식에서 **일반 이름**을 선택합니다. **UPN(사용자** **이름)**이 **대체 주체 이름에 이 정보 포함**에서 선택한 유일한 옵션인지 확인합니다. 5. **확장** 탭에서 **응용 프로그램 정책**에 **클라이언트 인증(OID 1.3.6.1.5.5.7.3.2)**만 포함되어 있는지 확인합니다. 또한 발급 정책을 편집하여 **낮은 보증** 정책을 추가합니다. 6. **보안** 탭에서 읽기, 등록 및 자동 등록 권한을 가진 **클라이언트 인증 - 사용자 인증서 자동 등록** 보안 그룹을 추가합니다. 이와 더불어 등록 또는 자동 등록 권한을 가진 다른 그룹은 모두 제거합니다. 컴퓨터 인증용 인증서 템플릿 만들기 이 인증서는 EAP-TLS 핸드셰이크 중에 컴퓨터가 IAS 서버를 인증하는 데 사용됩니다. 인증서 서비스 관리자는 다음 작업을 다시 한 번 수행해야 합니다. **컴퓨터 인증 인증서 템플릿을 만들려면** 1. 발행 CA에서 인증서 템플릿 MMC 스냅인을 실행합니다. 2. 워크스테이션 인증 템플릿을 복제합니다. 새 템플릿의 **일반** 탭에 있는 **템플릿 표시 이름** 필드에 **클라이언트 인증 – 컴퓨터**를 입력합니다. 3. **주체 이름** 탭에서 **이 Active Directory 정보로 만듦**을 선택합니다. **주체 이름 형식**에서 **일반 이름**을 선택합니다. **DNS 이름**이 **대체 주체 이름에 이 정보 포함**에서 선택한 유일한 옵션인지 확인합니다. 4. **확장** 탭에서 응용 프로그램 정책에 **클라이언트 인증(OID 1.3.6.1.5.5.7.3.2)**만 포함되도록 정책을 편집합니다. 또한 **발급** 정책을 편집하여 **낮은 보증** 정책을 추가합니다. 5. **보안** 탭에서 읽기, 등록 및 자동 등록 권한을 가진 **클라이언트 인증 - 컴퓨터 인증서 자동 등록** 보안 그룹을 추가합니다. 해당 권한을 가진 다른 모든 그룹은 제거해야 합니다. CA에 WLAN 인증 인증서 추가 인증서 템플릿이 구성되었으므로 이제 인증서 템플릿을 CA에 추가하여 등록해야 합니다. 이를 수행하려면 인증서 서비스 관리자가 다음 작업을 수행해야 합니다. **인증서 템플릿을 CA에 추가하려면** - 발행 CA에서 인증 기관 MMC 스냅인을 실행하고 **인증서 템플릿** 폴더를 마우스 오른쪽 단추로 클릭한 다음 **새로 만들기**, **발급할 인증서 템플릿**을 차례로 클릭합니다. 다음 인증서를 선택하고 **확인**을 클릭합니다. - 클라이언트 인증 - 컴퓨터 - 클라이언트 인증 - 사용자 - RAS 및 IAS 서버 인증 IAS 서버 인증서 등록 서버 인증 인증서를 IAS 서버에 배포하는 작업은 매우 간단하며 자동으로 수행할 수 있습니다. **IAS 서버를 등록하려면** 1. Active Directory 사용자 및 컴퓨터 MMC 스냅인을 실행하고 IAS 컴퓨터 계정을 RAS 및 IAS 서버 인증 인증서 자동 등록 보안 그룹에 추가합니다. 2. IAS 서버를 다시 시작하고 로컬 Administrators 그룹의 구성원으로 로그인합니다. 3. 명령 프롬프트에서 GPUPDATE /force를 실행합니다. 4. MMC를 열고 인증서 스냅인을 추가합니다. 컴퓨터 계정 옵션을 선택한 다음 로컬 컴퓨터를 선택합니다. 5. 콘솔 트리에서 **인증서(로컬 컴퓨터)**를 선택하고 **동작 메뉴**에서 **모든 작업**을 클릭한 다음 **인증서를 자동으로 등록**을 클릭합니다. **참고**   인증서 관리자 승인을 요청하는 옵션을 사용하고 있는 경우에는 CA 관리자가 이 요청의 유효성을 확인한 후 인증서를 발행해야 합니다. 자동등록 그룹에 사용자 및 컴퓨터 추가 WLAN 연결이 필요한 사용자와 컴퓨터는 발행된 사용자 및 컴퓨터 인증서가 있어야 네트워크를 인증하거나 무선 연결을 통해 네트워크에 액세스할 수 있습니다. 해당 인증서를 발행하고 갱신하는 프로세스는 앞에서 설정한 자동 등록 그룹으로 인해 최종 사용자에게 투명하게 진행됩니다. 사용자와 해당 컴퓨터를 자동 등록 그룹에 추가하려면 Active Directory 사용자 및 컴퓨터 MMC 스냅인을 사용하여 사용자 계정을 클라이언트 인증 - 사용자 인증서 자동 등록 그룹에 추가하고 해당 컴퓨터를 클라이언트 인증 - 컴퓨터 인증서 자동 등록 그룹에 추가하기만 하면 됩니다. 이 작업을 완료한 후 사용자가 자신의 컴퓨터를 다시 시작하고 네트워크에 다시 로그온하면 사용자 및 컴퓨터 인증서를 받을 수 있습니다. **참고**   이 솔루션에서는 사용자 지정 그룹을 사용하여 인증서를 받을 수 있는 사용자와 컴퓨터를 제어합니다. 모든 사용자와 컴퓨터에 인증서가 필요한 환경인 경우에는 도메인 사용자를 클라이언트 인증 - 사용자 인증서 자동 등록 그룹에 추가하고 도메인 컴퓨터를 클라이언트 인증 - 컴퓨터 인증서 자동 등록 그룹에 추가하기만 하면 됩니다. ###### WLAN 액세스 인프라 구성 주 IAS 서버는 WLAN에 대한 무선 클라이언트의 인증 및 권한을 결정하는 연결 요청 설정 및 원격 액세스 정책을 사용하여 구성해야 합니다. 이러한 설정은 나중에 다른 IAS 서버로 복제하여 무선 액세스 지점과 같은 RADIUS 클라이언트의 연결을 허용할 수 있도록 각 IAS 서버를 고유하게 구성해야 합니다. 이후에는 IAS 서버를 wireless 802.1X 네트워크의 인증 및 권한 부여 소스로 사용하도록 무선 액세스 지점 자체를 구성해야 합니다. WLAN용 IAS 원격 액세스 정책 만들기 원격 액세스 정책으로 IAS를 구성하려면 주 IAS 서버에서 인터넷 인증 서비스 MMC 스냅인을 다음과 같이 사용하십시오. **원격 액세스 정책을 만들려면** 1. **원격 액세스 정책** 폴더를 마우스 오른쪽 단추로 클릭하고 **새 원격 액세스 정책 만들기**를 클릭합니다. 2. 새 정책의 이름을 **무선 액세스 허용**으로 지정하고 마법사를 사용하여 **일반 시나리오에 대한 일반 정책**을 설정합니다. 3. 액세스 방법으로 **무선**을 선택합니다. 4. 그룹 기반으로 액세스를 허용하고 원격 액세스 정책 - 무선 액세스 보안 그룹을 사용합니다. 5. **EAP(확장할 수 있는 인증 프로토콜) 유형에 대해 스마트 카드 또는 기타 인증서**를 선택한 다음 IAS용으로 설치된 서버 인증 인증서를 선택합니다. 6. 작업을 완료하고 마법사를 끝냅니다. 7. 무선 액세스 허용 정책의 속성을 열고 **프로필 편집**을 클릭합니다. 8. **고급** 탭에서 **Ignore-User-Dialin-Properties** 특성과 **Termination-Action** 특성을 차례로 추가한 다음 각각 **True**와 **RADIUS 요청**으로 설정합니다. **참고**   무선 액세스 허용 정책은 사용자가 만든 다른 정책 또는 기본 액세스 정책과 함께 사용할 수 있지만, 제대로 작동하도록 하려면 원격 액세스 정책 폴더에서 기본 원격 액세스 정책을 무선 액세스 허용 정책 뒤에 나열해야 합니다. IAS에 RADIUS 클라이언트 추가 무선 액세스 지점 및 RADIUS 프록시를 RADIUS 클라이언트로 IAS에 추가해야 RADIUS 프로토콜을 통해 인증 및 계정 서비스를 사용할 수 있습니다. **RADIUS 클라이언트를 IAS에 추가하려면** 1. 인터넷 인증 서버 MMC 스냅인을 실행합니다. 2. **RADIUS 클라이언트** 폴더를 마우스 오른쪽 단추로 클릭하고 **새 RADIUS 클라이언트**를 클릭합니다. 3. 무선 액세스 지점의 이름과 IP 주소를 입력합니다. 4. 클라이언트-공급업체 특성으로 RADIUS 표준을 선택하고 해당하는 특정 무선 액세스 지점에 대한 공유 암호를 입력합니다. 그런 다음 **요청에 메시지 인증자 특성이 포함되어야 함** 특성을 선택합니다. **참고**   이 프로세스는 서버마다 고유한 무선 액세스 지점 클라이언트 및 공유 암호가 지정될 수 있도록 각 IAS 서버에서 반복해야 합니다. 이 프로세스를 단순화하기 위해 이 가이드에서는 공유 암호를 생성하고 시스템을 복원해야 하는 경우 해당 암호를 안전한 위치에 저장하는 일련의 과정을 수행하는 스크립트를 제공합니다. 이 스크립트를 사용하려면 명령 프롬프트에서 다음을 실행하십시오. ``` Cscript //job:GenPWD C:\\MSSScripts\\wl\_tools.wsf /client:ClientName ``` ###### 다중 IAS 서버에 구성 배포 다음 항목이 주 IAS 서버에 구성되면 **netsh** 명령을 사용하여 텍스트 파일로 내보낼 수 있습니다. 내보내기가 완료되면 이 텍스트 파일을 환경 내에서 유사한 역할을 가진 각 IAS 서버로 가져올 수 있습니다. 이렇게 하면 환경 전체에서 공통 구성을 유지할 수 있습니다. 내보낼 수 있는 구성 설정에는 다음이 포함됩니다. - 서버 설정 - 로깅 구성 - 원격 액세스 정책 - RADIUS 클라이언트 - 전체 구성 각 IAS 서버에는 고유의 RADIUS 클라이언트 및 공유 암호 목록이 있습니다. 따라서 이러한 정보는 각 서버에서 개별적으로 구성되어야 하며 별도로 백업해야 합니다. 또한 전체 구성 덤프에는 매우 중요한 정보가 포함되어 있으며 이 정보가 노출될 경우 무선 네트워크에 액세스하는 데 사용될 수 있으므로 보안을 유지하는 데 각별히 유의해야 합니다. 주 IAS 서버 구성 내보내기 다른 IAS 서버에 복제하기 위해 다음 설정 유형을 텍스트 파일로 내보내야 합니다. - 서버 구성 - 로깅 설정 - 원격 액세스 정책 - 연결 요청 정책 이 프로세스를 단순화하기 위해 가이드에서는 **netsh** 명령이 포함된 배치 파일을 제공합니다. 이 파일은 명령 프롬프트에서 다음을 실행하여 공통 구성 정보를 D:\\IASConfig 디렉터리의 텍스트 파일로 내보낼 수 있습니다. ``` C:\\MSSScripts\\IASExport.bat ``` 주 IAS 서버에서 구성 정보 가져오기 IAS에서는 **netsh** 명령을 사용하여 구성 상태를 한 서버에서 다른 서버로 전송합니다. 이렇게 하면 구성 프로세스를 수행하는 동안 오류가 발생할 가능성을 줄이면서 보다 효율적으로 배포할 수 있습니다. 주 IAS 서버의 구성 정보를 내보냈으므로 이제 보조 IAS 서버에서 해당 구성 상태를 가져올 수 있습니다. **주 IAS 구성 상태를 다른 IAS 서버로 가져오려면** 1. 주 IAS 서버의 D:\\IASConfig 디렉터리에서 모든 구성 파일을 복사하여 다른 IAS 서버의 D:\\IASConfig 디렉터리에 붙여 넣습니다. 2. 구성 상태를 가져오려면 보조 서버의 명령줄에서 다음 배치 파일(이 가이드에 포함)을 사용합니다. ``` C:\\MSSScripts\\IASImport.bat ``` ##### 무선 액세스 지점 및 클라이언트 무선 액세스 지점을 구성하는 절차는 사용 중인 장치의 제조사 및 모델에 따라 약간씩 다를 수 있습니다. 그러나 무선 액세스 지점 공급업체에서는 일반적으로 다음과 같은 필수 정보와 함께 장치 구성을 위한 자세한 지침을 제공합니다. - 802.1X 네트워킹 설정 - 주 RADIUS 서버 주소 구성 - 보조 RADIUS 서버 주소 구성 - 주 RADIUS 서버와 공유되는 RADIUS 암호 - 보조 RADIUS 서버와 공유되는 RADIUS 암호 특정 무선 장비 브랜드 및 모델의 구성에 관한 지침은 해당 공급업체 지침 또는 지원 웹 사이트를 참조하십시오. ###### WLAN 인증 인증서 배포 이 섹션에서는 Windows XP 기반 클라이언트의 인증서를 자동으로 등록하는 데 필요한 몇 가지 중요한 구성 작업에 대해 설명합니다. 이전 섹션에서도 인증서 인프라에서 인증서의 자동 등록을 지원하기 위한 정책 및 템플릿 사용에 대해 설명했지만 Windows XP에서는 이 기능이 기본적으로 사용되지 않습니다. 인증서 자동 등록에 대한 지원을 사용하려면 그룹 정책을 통해 설정을 올바로 구성해야 합니다. 보안 그룹을 사용하여 자동 등록을 제어하면, 도메인 내의 모든 사용자 및 컴퓨터에 대해 이 기능을 사용할 수 있으며 보안 그룹에서 인증서 종류별로 수신자를 결정할 수 있습니다. **도메인 내의 모든 사용자 및 컴퓨터에 대해 자동 등록을 사용하려면** 1. GPO를 만드는 권한과 GPO를 도메인에 연결하는 권한이 있는 계정으로 로그인합니다. 2. Active Directory 사용자 및 컴퓨터에서 도메인 개체를 선택하고 마우스 오른쪽 단추로 클릭한 다음 속성을 클릭합니다. 3. **그룹 정책** 탭에서 **새로 만들기**를 클릭하고 해당 GPO 이름(예: 도메인 PKI 정책)을 입력합니다. 4. **편집**을 클릭하고 컴퓨터 구성\\Windows 설정\\보안 설정 아래의 **공개 키 정책**을 찾아 이동합니다. 5. **세부 정보** 창에서 **자동 등록 설정**을 두 번 클릭합니다. 6. 다음 항목이 선택되었는지 확인합니다. - 인증서를 자동으로 등록 - 만료된 인증서 갱신, 보류 중인 인증서 업데이트, 해지된 인증서 제거 - 인증서 템플릿을 사용하는 인증서 업데이트 7. 사용자 구성\\Windows 설정\\보안 설정\\공개 키 정책의 사용자 자동 등록 설정에 대해 5-6단계를 반복합니다. 8. GPO를 닫습니다. 9. 이 GPO가 기본 도메인 정책 GPO보다 우선 순위가 높은지 확인합니다. 10. 다중 도메인 포리스트에 있다면 인증서 자동 등록을 사용할 각 도메인에 대해 이 프로세스를 반복합니다. **참고**   사용자가 로밍 프로필을 사용하지 않고 자동 등록을 보편적으로 적용하면 로그온하는 모든 컴퓨터의 사용자에 대해 인증서가 발행됩니다. 이는 관리자 권한이 있는 사용자가 서버에 로그인하는 경우에는 적절하지 못할 수 있습니다. 이런 일이 발생하지 않도록 자동 등록을 사용하지 않는 서버에 대해 GPO를 만드는 것이 좋습니다. 또한 모든 사용자에게 자동 등록을 사용하는 것이 바람직하지 않다면 자동 등록이 필요한 사용자의 하위 집합을 포함하는 OU에 GPO를 연결할 수도 있습니다. ###### 사용자 및 컴퓨터의 WLAN 액세스 사용 사용자와 컴퓨터에 보안 WLAN 액세스를 활성화하기 위한 마지막 단계에서는 Active Directory 개체에 대해 몇 가지 작업을 수행해야 합니다. 이러한 작업에는 계정 권한/그룹 권한 수정 및 WLAN 그룹 정책 설정 구현이 포함됩니다. 원격 액세스 정책 그룹에 사용자 추가 IAS 원격 액세스 정책은 Active Directory 기반 보안 그룹을 사용하여 사용자와 컴퓨터가 WLAN에 연결할 수 있는 권한이 있는지 확인합니다. 이러한 보안 그룹에는 다음이 포함됩니다. - 원격 액세스 정책 - 무선 사용자 - 원격 액세스 정책 - 무선 컴퓨터 - 원격 액세스 정책 - 무선 액세스 **사용자 및 컴퓨터를 WLAN 액세스 그룹에 추가하려면** 1. Active Directory 사용자 및 컴퓨터 MMC 스냅인을 엽니다. 2. Active Directory 사용자 및 컴퓨터 MMC 스냅인을 사용하여 원격 액세스 정책 - 무선 사용자 그룹 및 원격 액세스 정책 - 무선 컴퓨터 그룹을 원격 액세스 - 무선 액세스 그룹에 추가합니다. 3. WLAN 액세스가 허가된 사용자를 원격 정책 – 무선 사용자 그룹에 추가합니다. 4. WLAN 액세스가 허가된 컴퓨터를 원격 정책 – 무선 컴퓨터 그룹에 추가합니다. **참고**   모든 사용자 및 컴퓨터가 기본적으로 WLAN에 액세스할 수 있도록 허용하는 것이 적절하다고 판단되면 도메인 사용자 및 도메인 컴퓨터 그룹을 해당 정책 그룹에 추가하여 간편하게 관리할 수 있습니다. Active Directory WLAN 그룹 정책 만들기 Windows Server 2003의 그룹 정책 MMC에는 802.1X 및 802.11 표준과 관련된 무선 네트워크 정책 설정이 포함되어 있기 때문에 그룹 정책을 사용하여 클라이언트 컴퓨터의 WLAN 구성 설정을 자동화하고 적용할 수 있습니다. **무선 네트워크 그룹 정책을 만들려면** 1. Windows Server 2003 기반 서버 또는 Windows Server 2003 관리 도구가 설치되어 있는 워크스테이션에서 Active Directory 사용자 및 컴퓨터 MMC 스냅인을 엽니다. 2. 도메인 개체의 속성을 선택하고 **그룹 정책** 탭에서 **새로 만들기**를 클릭한 다음 GPO 이름을 무선 네트워크 정책으로 지정합니다. 3. **속성** 단추를 클릭하고 **보안** 탭에서 무선 네트워크 정책 - 컴퓨터 보안 그룹에 그룹 정책 읽기 및 적용 권한을 부여합니다. 또한 GPO의 인증된 사용자에서 그룹 정책 적용 권한을 제거합니다. 4. **일반** 탭에서 정책 개체에 대해 **사용자 구성 설정 사용 안 함**을 선택하고 나타나는 모든 경고 메시지에 대해 **예**를 선택합니다. 변경 내용을 적용하고 창을 닫습니다. 5. **편집** 단추를 클릭하고 \\컴퓨터 구성\\Windows 설정\\보안 설정\\무선 네트워크(IEEE 802.11) 정책으로 이동합니다. 6. 탐색 창에서 무선 네트워크(IEEE 802.11) 정책을 선택하고 **동작** 메뉴에서 **무선 네트워크 정책 만들기**를 클릭합니다. 마법사를 사용하여 정책 이름을 **클라이언트 컴퓨터 무선 구성**으로 지정합니다. 선택한 **속성 편집** 옵션을 그대로 두고 **마침**을 클릭하여 마법사를 닫습니다. 7. **클라이언트 컴퓨터 무선 구성** 정책의 **기본 설정 네트워크** 탭에서 **추가**를 선택하고 무선 네트워크의 네트워크 이름 또는 SSID(서비스 집합 ID)를 입력합니다. 8. **IEEE 802.1X** 탭을 클릭하고 **스마트 카드 또는 기타 인증서 EAP 유형**에 대한 설정을 엽니다. **신뢰할 수 있는 루트 인증 기관**에서 IAS 서버 인증서를 발행한 PKI의 루트 CA 인증서를 선택합니다. 9. 클라이언트 컴퓨터 무선 구성에 대한 속성과 그룹 정책 개체 편집기를 닫습니다. **참고**   현재 WPA2에서는 GPO를 사용할 수 없습니다. 그러나 Windows Vista 및 Longhorn에서는 WPA2의 GPO 지원이 구현될 것으로 예상되며 현재 Windows 릴리스에서도 이 문제를 해결하기 위한 업데이트가 계획되어 있습니다. WLAN 그룹 정책의 보안 그룹에 컴퓨터 추가 Active Directory 기반 보안 그룹은 어떤 컴퓨터에 무선 네트워크 정책을 적용하여 802.11 및 802.1X 설정을 자동으로 구성할지를 결정하는 데 사용됩니다. 이러한 설정은 모든 무선 액세스 지점에서 802.1X 설정을 구성하기 전에, 그리고 WLAN을 활성화하기 전에 배포해야 합니다. 이러한 접근 방법을 사용하면 유선 네트워크에 거의 연결하지 않는 클라이언트 컴퓨터인 경우에도 컴퓨터 기반 그룹 정책을 다운로드하고 적용할 충분할 기회를 가질 수 있습니다. 그룹 정책 설정은 WLAN NIC(네트워크 인터페이스 카드)를 설치하기 전에도 적용할 수 있는데, WLAN NIC는 올바른 무선 네트워크 그룹 정책 설정을 자동으로 검색하여 적용합니다. 컴퓨터를 무선 네트워크 그룹 정책의 그룹에 추가하려면 Active Directory 사용자 및 컴퓨터 MMC 스냅인을 사용하여 권한이 있는 컴퓨터 개체를 무선 네트워크 정책 - 컴퓨터 그룹에 추가하십시오. **참고**   무선 네트워크 GPO 설정은 다음 컴퓨터 그룹 정책의 새로 고침 간격 동안 클라이언트 컴퓨터에서 업데이트됩니다. 새로 고침을 적용하려면 GPUPDATE /force 명령을 실행하기만 하면 됩니다. ###### WPA2 클라이언트 요구 사항 이 가이드에 소개된 솔루션은 Windows XP Professional SP2 또는 Windows XP Tablet Edition을 사용하는 무선 가능 클라이언트 컴퓨터에 적합하게 디자인되었습니다. 이러한 버전의 Windows는 기본적으로 802.1X와 WLAN 지원을 제공합니다. 또한 Windows XP 기반 클라이언트는 자동 인증서 등록 및 갱신 기능을 제공하므로 인증서 기반 솔루션이 인증서 인프라와 결합될 경우 매우 경제적으로 운용할 수 있습니다. Windows XP SP2는 기본적으로 WPA 지원을 제공하지만 Windows XP SP2 기반 클라이언트에서 IEEE 802.11i WPA2 지원을 사용하려면 추가 업데이트를 설치해야 합니다. 다운로드 지침과 함께 추가 업데이트에 대한 자세한 내용을 보려면 [ Windows XP 서비스 팩 2용 WPA2/WPS IE 업데이트를 사용할 수 있다](https://support.microsoft.com/default.aspx?scid=kb;ko-kr;893357)(https://support.microsoft.com/default.aspx?scid=kb;ko-kr;893357)를 참조하십시오. [](#mainsection)[페이지 위쪽](#mainsection) ### 요약 이전 무선 보안 표준에서 잘 알려진 결함을 해결하는 데 사용되는 다양한 솔루션을 검토하는 동시에 그러한 해결 방법들이 어째서 기업 표준으로 더 이상 사용되지 않는지를 이해하면 중소 기업 환경의 무선 네트워크 보안을 향상시킬 수 있는 솔루션이 명확해집니다. 이제 중소 기업에서는 이 가이드에서 제공하는 솔루션인 인증서 서비스와 함께 WPA 또는 WPA2 EAP-TLS를 사용하는 접근 방법을 사용하여 보다 안정적으로 생산성을 향상시킴으로써 이 가치 있는 기술을 효과적으로 구현할 수 있습니다. 이 문서에서 설명하는 대로 세부 단계를 따르고 도구를 사용하여 생산성을 향상시킬 수 있는 안전하고 신뢰할 수 있는 무선 솔루션을 구축하십시오. **다운로드** ['무선 액세스 지점 구성 보호' 문서 보기 (영문)](https://go.microsoft.com/fwlink/?linkid=71716) [](#mainsection)[페이지 위쪽](#mainsection)
  • Last updated on