로그 관리 방법 정리

로그는 크게 3가지 정도 분류된다.
Windows Events Log, Syslog messages, SNMP trap messages

각각을 하나로 모으는 과정은 아래 몇가지 방법을 이용한다.

1. Syslog를 이용하여 유닉스 및 network device들의 log 집중 관리
- syslog는 그자체로 훌륭한 중앙 로그집중 관리툴이다.
- syslog는 산업 표준 logging system으로 대부분의 유닉스(리눅스 포함)및 네트웍 장비들이 지원한다.

2. rsyslog를 이용하여 syslog forwarding
- rsyslog는 syslog message를 수신하면서 동시에 다른 syslog server로 log를 forwarding한다.
- 네트웍 구간별로 syslog server가 존재한다면 각 구간별 syslog server에는 rsyslog를 설치하여 log를 중앙으로 forwarding해준다.

3. Log management tool을 이용한 로그 수집
- Log management tool을 로그의 수신, 분석 및 저장 역할을 담당한다.
- syslog및 windows events를 모아서 분석하고 리포팅하며 또한 Database에 저장한다.
- 페이게이트는 GFI EventsManager를 이용중
- DB에 저장된 로그는 검색이 가능하며 PCI DSS의 로그보관정책에 따라 Tape에 백업해둘수도 있다.

------------------
전체 구조를 flow로 구성해보면
(Unix & Network device log)
-> rsyslog server(네트웍 구간별로 존배)
-> central rsyslog server
-> Log management tool
-> Database
-> Backup Tapes

의 로그흐름이 생성된다.

모의해킹 방법

PCI DSS Requirements 11 에서 모의해킹(Penetration test)을 요구한다.
아래 간단한 모의해킹 방법을 정리해보았다.

1. download metasploit tool
http://www.metaspolit.com

2. open port scan with zenmap(nmap tool gui version)
target IP들에 대해서 open port가 있는 IP들을 scan한다.
IP대역 지정은 CIDR 포맷이나 range로 지정가능하다.
CIDR 예: 211.53.212.0/24
IP range : 21.53.212.1-254

3. port가 열려있는 IP들에 대해서 nessus vulnerability scan을 수행
만일 high vulnerabilities가 발견된다면

4. metasploit tool을 이용하여 exploit test 수행
- 발견된 취약점 형태에 따른 적절한 metasploit module을 선택하여 모의해킹 수행

-----------
위 절차는 사무실내에서(internal penetration test)와
사무실 외에서(external penetration test)에서 수행해야한다.

실제 모의해킹은 network에 대해서와 application에 대해서 시도해봐야하는데
위 절차는 network에 대한 절차이고 application에 대해서는 OWASP Top10 vulnerability guide에 의해 자체적으로 별도 수행해야한다.

-----------

참고로 일부 ASV scan 업체의 경우 ASV scan과 함께 penetration test 동시에 수행하고 결과를 제공하기도 한다.

PCI DSS 주기적으로 해야할 체크리스트

PCI DSS 감사를 매년 진행하면서 이미 진행했어야 하는 사항을 빠트리기 쉽고 과거진행했어야 할 사항은
감사시점에서 증빙을 제시하기 어려운것이 많으므로 미리미리 준비해야한다.

1. 매일 체크해야할 사항
- Log Reviews for Servers and network devices

2. 매주 체크해야할 사항
- File Integrity monitoring Review
- Anti-virus scan reports

3. 매월 체크해야할 사항
- 보안패치 반영사항

4. 분기별 확인사항
- 카드번호 검색 (데스크탑, 파일서버 및 데이터베이스)
- 내부 취약점 Scanning
- 모든 공개 IP에 대한 ASV scanning
- 유저 Account Privilege Review and removal of users not logged in last 90 days
- 무선망 취약점 분석

5. 반기별 확인사항
- 방화벽 및 라우터 룰셋 점검

6. 연간 확인사항
- 매년 암호화 키 로테이션
- Physical Security Review of Off-site Tape Backup location
- Media Inventories of medias stored onsite and offsite locations
- Internal Penetration Testing (Network and Application)
- Risk Assessment for the environment in scope
- External Penetration Testing (Network and Application)
- Policies & Procedures Review
- Incident Response Testing
- Information Security Awareness Training
- Sign-off from employees that they have read and understood the information security policies and procedures

SSH Port Forwarding

LAN to WAN direct outbound 금지에 대해서 고민하던중
SSH Port forwarding을 적용하기로 하였다.
일단 TCP protocol에 대해서만 적용가능하므로
Application Server에서 outbound access가 필요한 경우
HTTP Forward Proxy를 사용하거나 SSH Port Forwarding을 사용하면
대부분의 외부 접근 문제를 해결할 수 있다.

단 현재까지 아직 검증되지 않은 사항은
장애발생시 Failover나 얼마나 안정적으로 동작할것인지
그리고 어느정도의 추가 부하가 생길것인지 가늠하기가 어렵다.

OpenSSH가 무난하고
Client와의 연계를 위해서는 VanDyke software의 SecureCRT를 함께 검토중이다.

Anti DDoS 장비가 IDS의 일종인가?

Anti DDoS장비를 IDS로 볼 수 있는지에 대한 의견이 분분합니다.
일단 저는 Anti DDoS장비를 IDS/IPS의 일종으로 보고 있습니다.
IDS/IPS 설치는 PCI DSS Requirements중 하나이고 전자금융거래법 시행세칙에서도 요구되고 있습니다.
정확한 사항은 QSA의 답변을 받아봐야할것 같습니다.

OSI Layer 1에서부터 7까지중 어디까지 Detect하느냐가 기존의 IDS와 Anti DDoS장비의 중요한 차이점이고
PCI DSS Requirements에 OSI 7 Layer 수준까지 명시하고 있지는 않아서
QSA의 판단에 따라서 보완통제를 적용하든 적용없이 인정할 수 있겠다는 생각입니다.

Forward Proxy

Forward Proxy가 LAN area의 서버에서 Direct outbound access 금지 규정에 대한 훌륭한 솔루션임을 확인하였습니다.

HTTP/HTTPS outbound access가 필요한 다양한 Application에서 forward proxy를 이용할 수 있도록 기본 지원합니다.

검토한 Application등은 아래와 같습니다.
* yum update 시 proxy server 지정가능
* windwos update시 IE 연결 설정에서 proxy server 지정가능
* apache commons httpclient library에서 proxy server 지정가능
* wget과 같은 command line tool에서 proxy server 지정가능.

Proxy server 이용시 다양한 추가 정책을 설정하여 보안을 강화할 수 있습니다. (유저인증, Source IP제한, Target IP 제한 등)

ActiveDirectory 정책으로 이용하는 모든 PC에서 Default Proxy Server를 강제 설정할 수 있도록 지원하는것도 확인하였습니다.

cache기능을 함께 이용하면 OS Update에 대한 traffic 감소 효과도 있을것으로 예상합니다.

List of Compliant Service Providers

전세계 PCI DSS 인증받은 Service Provider 목록이 있습니다.

Asia Pacific 지역은 www.visa-asia.com/spregistry 에서 확인가능하며
전세계 모든 지역에 대한 목록은 www.visa.com/splisting 에서 확인가능합니다.

spregistry에 등록하는것은 연간 5천불의 비용이 드는데 한국의 경우 Visa에 한정된 범위내에서 무료 등록 지원을 해주고 있습니다.

visa-asia.com site는 update가 좀 늦는군요.

알고 있는 회사가 존재하는지 찾아보세요

Master Card 목록은 여기에 있군요.
http://www.mastercard.com/us/sdp/assets/pdf/Compliant%20Service%20Providers%20-%20November%2016%202009.pdf

GoogleGroups 생성

PCI DSS관련 토의를 좀더 활발하게 하기 위하여 GoogleGroups를 생성하였습니다.

E-Mail 주소 : pcidssguide@googlegroups.com
Web 주소 : http://groups.google.com/group/pcidssguide

Blog에 포스팅하는 내용이나 댓글이 Groups에 자동 등록되도록 설정되었습니다.

PCI DSS 요구사항 요약정리

Requirements를 단위 갯수로 계산해보면 120개가 넘습니다.
그리고 각 조항의 세부항목을 모두다 읽어가다보면 숲(Wide View)을 보지 못하는 오류가 생기기 쉽습니다.

간단하게 requirements를 분류해두는 경우 각 항목별 이해도를 높이는데 도움이 됩니다.

[안전한 네트웍 구성을 위한 요구사항들]
Requirement 1 : 주로 방화벽 구성 관련 요구사항들
Requirement 2 : System Configuration 관리에 대하여 기술하고 있습니다.
각 시스템의 구성이나 설정방법으로 미리 기술하고 관리하자는 취지입니다.

[고객 카드정보 보호]
Requirement 3 : 카드정보 암호화 및 키관리 관련
Requirement 4 : 전송중인 데이터 보호 관련

[취약점 관리]
Requirement 5 : 바이러스 방지
Requirement 6 : 안전한 시스템 및 어플리케이션 개발

[접근통제]
Requirement 7 : 필요한 경우만 접근한다는 원칙
Requirement 8 : ID 관리
Requirement 9 : 물리적 접근통제

[모니터링 및 테스트]
Requirement 10 : 침입대응 모니터링
Requirement 11 : 취약점 테스트

[정책관리]
Requirement 12 : 보안 정책 관리

보완통제(Compensating Controls)

모든 PCI DSS requirements는 예외사항이 존재할 수 있습니다.
예를 들어 서버중 하나가 아주 오래된 Legacy system이고 허용하는 패스워드 최대자리수가 6자리라면 7자리까지 요구하는 PCI DSS의 규정을 달성할 수 없습니다.
그렇다고 튼튼하게 잘 돌아가는 legacy system을 패스워드 자릿수때문에 교체해야할까요?
그렇지 않습니다.

PCI DSS requirements Appendix B에서 보완통제에 대해서 자세히 기술하고 있는데
주요 내용은 모든 requirements 조항들에 대해서 다른 대안등이 고려될 수 있다는 것입니다.

requirements가 기술된 근본 이유를 파악하여 그에 상응하는 다른 대안을 준비하는 경우 QSA의 충분한 리뷰이후에 그 대안으로 요구사항들을 충족하는것으로 확인될 수 있습니다.

이부분은 PCI DSS 대응에 대한 상당한 유연성을 제공하는 규정입니다.

LAN Network에서의 outbound access

LAN Network에서 outbound access를 금지하는 규정이 PCI DSS requirements에 명시되어 있습니다.

그러나 현실은 LAN Network에서의 direct outbound access가 필요한 경우가 상당히 많습니다.

예를 들어
Linux OS Auto Update는 여전히 outbound access가 필요하며
또한 Partner 회사와 인터넷 VPN으로 통신하는 경우에는 outbound access가 필요합니다.

OS auto update가 DMZ에 존재하는 proxy나 os update repository를 통해서도 진행가능하지만
현실적으로 추가적인 하나의 Machine이 필요하거나 Vendor에서 정식으로 제공하지 않아서 구현하기 어려운 경우들이 상당수 존재합니다.

requirements 1.3.*에서 요구하는 outbound access 제한의 근본 취지는
어떤 해커가 시스템에 침입하여 주요 정보를 빼내가는 것을 방지하기 위해서 존재하는 규정이고
이것을 충족할 수 있다면 제한된 범위에서 outbound access가 허용될 수 있다는 QSA(mike)의 의견입니다.

즉 LAN Area에서 무조건적으로 DMZ내의 IP가 아닌 internet으로의 outbound access를 막는것은 아니고
outbound access를 통제하면서 제한적으로 허용될 수 있습니다.

partner사와의 VPN 통신시 outbount access target IP를 partner사로만 한정하는 경우 requirement구성의 근본 취지를 충족하면서 충분히 안전하게 처리가능합니다.

또한 OS Update시의 target server를 충분히 통제한다면 역시 LAN area에서의 outbound access가 허용될 수 있습니다.

이렇게 허용할 수 있는 근거는
requirements appendix B. Compensating Controls(보완 통제)에서 자세하게 다루고 있습니다.

가상화 기술 이용

비자 교육과정에서 처음 문의한것이 가상화 기술의 사용 부분이었다.

현재 시중의 주요 가상화제품군은 2종류(*)로 구분해보면
[Hypervisor 계열 제품들]
VMWare ESX
Sun LDOM
MS Hyper-V

[특정 OS위에서 운영되는 가상화 제품들]
VMWare Workstation
Sun Solaris Container
MS Windows 2008 Server Hyper-V

으로 분류해볼 수 있고

VM Host의 Physical Ethernet Cable을 DMZ과 LAN Area에 연결해두고
VM Guest들이 이들 네트웍 구간에 위치시키는 경우

해당 네트웍에 존재하는 서버들로 인정하여 PCI Audit에는 문제없다는 의견을 받음 (from Mike)

구상해볼 수 있는 네트웍 구성은

5개의 네트웍 구간을 준비하고
- Production DMZ
- Production LAN
- Staging DMZ
- Staging LAN
- Office Network

VMHost를 Office Network에 위치시킴.
Office Network은 Production이나 Staging 어디에도 속하지 않는 독립된 네트웍이고
VMHost에 4개의 추가 Ethernet Port를 확보하고 각각을 Production이나 Staging의 DMZ/LAN에 캐이블을 연결
이 Ethernet Port들은 VMGuest에서 사용되도록함.

VMGuest를 생성할때 Virtual Ethernet Device를 어느 네트웍에 속하는 것을 선택하는지에 따라 생성된 Virtual Machine이 DMZ이나 LAN Area에 위치시킬 수 있음.

가상화 기술의 장점이 물리적인 Resource를 Share할 수 있는 것이고
8core 32GB machine정도면 약 10개 정도의 VMGuest들을 만들어낼 수 있음.

Sun LDOM은 더 많이 만들어낼 수 있다고 하는데 한번 봐야하고

이걸로 최소한 PCI DSS준비하면서 Server가 부족한 상황은 해소가능하겠다.

[비용은]
x86계열은 VMWare ESX (무료)
Sparc Solaris는 LDOM (무료)

다른 플랫폼은 얼마인지 모름

비자인터네셔날 PCI DSS 교육

4월 9일, 10일 양일간 비자인터네셔널 주최로 소공동 롯데호텔에서
PCI DSS 관련 교육이 있었습니다.
PG사들, 대형 쇼핑몰, 그리고 카드사에서 참석하였고
약 30분이 열심히 교육을 받았습니다.

강사님은 Michael Dahn씨인데 마이크라고 부르더군요.

교육내용은 보안침해사례 검토, 적용범위, 보완통제 그리고 요구사항 분석등의 절차로 진행하였고
교육과정에서 확인한 중요사항을 추가로 정리해서 올리겠습니다.

국내 PCI DSS 인증업체목록

현재까지 국내에서 PCI DSS 인증을 통과한것으로 여겨지는 업체 목록입니다.

PayGate (www.paygate.net)
KSNET (www.ksnet.co.kr)
FirstData (www.firstdatacorp.co.kr)
NICE (www.nicevan.co.kr)
Smartro (www.smartro.co.kr)
KISVAN (www.kisvan.co.kr)
KOVAN (www.kovan.co.kr)
KCP (www.kcp.co.kr)
StarVAN (www.starvankorea.com)
LGDacom (www.lgdacom.net)
KOCES (www.koces.com)
JTNET (www.jtnet.co.kr)
AllAt (www.allat.co.kr)
INICIS (www.inicis.co.kr)
CyberPass (www.cyberpass.com)
HyoSung (www.hyosung.com)

총 16개 업체인데
이중 일부는 실사를 받기는 하였지만 100% Full Compliant 달성하지 못한 업체도 있을것으로 예상됩니다.

대부분 VAN및 PG사들이고 대형쇼핑몰업체는 아직 목록에 없군요.

PCI DSS version 1.1과 1.2 차이 요약

1.1과 1.2 두 버전간의 차이점에 대한 요약입니다.

모든 변경사항에 대한 비교 정보는
https://www.pcisecuritystandards.org/pdfs/pci_dss_summary_of_changes_v1-2.pdf
에서 확인가능합니다.

1.1.5~7까지의 requirements가 1.1.5 하나로 통합되었습니다.
실제 준비해나가다 보면 firewall configuration을 protocol 종류별로 따로 구분 관리하지는 않으므로 자연스러운 개선입니다.

1.1.8에서는 firewall ruleset 정기점검을 과거 분기 한번할것을 6개월에 한번 하면 되는것으로 완화되었습니다.

2.1.1에서는 WEP 무선보안 방식의 사용을 이제는 사실상 금지하도록 강화되었습니다. (WEP 사용금지는 4.1.1에서 다시한번 언급됩니다. 이미 WEP을 사용하고 있더라도 2010년 6월 30일까지는 폐기하도록 강요하는군요)
그리고 SSID broadcast가 다시 허용되는군요.

4.2에서는 예전 E-Mail Security만 언급하던데서 확장하여 End-User Messaging technologies로 정의하면서 여기에 E-Mail, Instant messaging, chat등이 포함되는군요.

6.5에서 최신 OWASP 10대 보안취약점에 대한 사항이 대폭 반영되었습니다.
버전 1.1에서는 OWASP 2004년도 버전을 기반으로 하였다면 1.2에서는 OWASP 2007년 버전으로 개편되었군요.

9.5 백업 미디어 체크는 최소한 1년에 한번 하도록 명시되었습니다.

11.1에서는 Wireless IDS/IPS 구현에 대한 옵션이 추가되었군요. 조만간 이것도 의무화될것으로 예상됩니다.

11.4 IDS/IPS적용 범위를 모든 네트웍 트래픽에서 카드정보저장 환경에 대한 트래픽으로 범위가 줄었습니다. (비용절감)

12.3에서는 근로자의 정보기기 사용통제에 대한 범위가 좀더 명확해졌습니다. (원격접근, 무선기기, 휴대용미디어, 이메일사용, 인터넷 사용, 랩탑, PDA등)

12.3.*의 모뎀 관련된 규정은 "Remote Access Technologies"로 변경되었군요. 모뎀은 사용하지 않아서 그냥 pass했었는데 챙겨봐야할 규정이 늘었습니다.

기타 다른 변경사항들도 많지만 Impact가 느껴지는 조항들은 앞서 언급한것들이군요.

PCI DSS version 1.2

얼마전 새로 발표된 PCI DSS version 1.2 입니다.
2008년 10월 1일자로 기존 버전 1.1을 대치하게 되며
버전 1.1은 2008년 12월 31일까지만 유효하군요.

https://www.pcisecuritystandards.org/security_standards/pci_dss_download.html

QSA관련

QSA(Qualified Security Assessor)는 개인을 지칭하는 용어이자 회사를 의미합니다.

PCI DSS인증과정에서는 꼭 현장 실사를 거치게 되는데
이때 직접 실사를 나오는 개인이 QSA자격을 가지고 있는 사람이어야합니다.

그런데 QSA는 개인이 자기혼자 딸 수 있는건 아니고 꼭 회사의 직원일 경우에만 QSA로 인정받을 수 있습니다.

회사가 하는 역할중 중요한 것은 직원인 QSA의 신뢰성에 대한 보장을 보험으로 제공해야하며
보험가액이 $1,000,000은 됩니다.
보험은 그외에도 다른 요구사항들을 커버합니다.

이렇게 회사와 직원이 아주 밀접하게 결합되어 하나의 QSA가 탄생됩니다.

직원인 QSA는 PCI 위원회에서 개최하는 교육가서 교육받고 시험치르고 통과해야합니다.
CISSP, CISA, CISM중 하나라도 자격증이 있으면 몇가지 혜택이 있군요.

전세계 모든 QSA 목록은 PCI SSC website에서 제공합니다.
https://www.pcisecuritystandards.org/pdfs/pci_qsa_list.pdf

QSA별 비지니스 지역이 표시되어 있고 연락처도 있습니다.
국내에서는 A3 Security가 확인되는군요.

한가지 확인할것은 Supported Languages항목을 보면 Korean을 지원하는 QSA가 상당히 됩니다.

페이게이트 인증을 담당한 ControlCase Inc.(www.controlcase.com)도 그중 한 회사이지요.

PCI 위원회에서는 실사를 거친후 보고서를 요구하는데 이 보고서 언어는 무조건 영어여야한다고 못박고 있습니다.

QSA를 통한 인증과정은 대략 아래와 같습니다.
회사는 Requirements에 대한 확인 및 필요시 보완한이후
각각에 대한 증빙(Evidence)를 준비하여 QSA에게 review를 요청합니다.
QSA의 review이후 evidence를 확정하고
모든 evidence가 100% 준비된것 확인하고 실사하러 옵니다.
실사에서는 evidence가 사실인지 여부를 비교하고 remote로는 확인이 불가한 항목들에 대해서 확인을 진행합니다.
예를 들어 카드번호가 암호화되어 있다는 증빙을 screenshot떠서 보내면 나중에 와서 sample data에 대해서 직접 cardnumber search를 해보고 없음을 확인하는 식입니다.
이렇게 실사를 거치고 돌아가서 RoC (Report on Compliance)를 준비합니다.
RoC는 Evidences와 함께 또다른 QSA에 의한 Cross 검증을 진행한 후 확정합니다.
확정된 RoC는 피인증업체에 제공되고 PCI 위원회에도 보고됩니다.

Log Management

로그관리는 어렵고 재미있고 비지니스에도 도움이 됩니다.

로그 종류는 통상 3가지 정도 됩니다.
- Windows Event Log
- Syslog
- snmp trap message

로그를 남기는 object들은 아래 목록에 대부분 포함됩니다.
- OS
- Web Server와 같은 common application
- 각종 network devices (무선 장비 포함)
- 자체 application

[file integrity check]
로그내용이 중간에 제3자가 임의로 변경하지 못하도록 하기 위하여
권한설정도 철저해야하며
또한 로그내용의 변경여부를 감지할 수 있어야합니다.
로그파일의 특성상 항상 내용이 기록되고 있어 이에 대응되도록 file integrity checking software를 설정해야합니다.
tripwire가 대표적인 tool이긴 한데 windows용으로는 다루기 어렵고
상용은 비싸고 너무 무겁습니다.
ossec(www.ossec.net)을 권장합니다. unix나 windows모두 커버가능하며 가볍로 로그분석이나 Host based IDS역할을 함께 수행합니다.

[central log server]
로그를 중앙 집중 관리하는것이 PCI DSS의 요구사항중 하나입니다.

일반적인 syslog를 사용하면 각 개별서버에서 1차 집중 서버로 로그를 모으는것은 가능한데 여기서 다시 다른 통합 서버로 log forwarding이 잘 안됩니다.
rsyslog가 이러한 요구사항에 아주 잘 대응되는 무료 서버입니다.
각 서버들에서 네트웍 단위별 rsyslog 서버로 로그를 모으로 다시 여기서 중앙 log server로 forwarding하는등의 구성이 아주 간단합니다.

windows event log까지 통합 관리하기 위해서는
상용 tools이 필요하며
여기에는 Cisco MARS나 GFI EventsManager등을 이용할 수 있습니다.

중앙 로그 서버에 모인 로그는 3개월간의 데이터까지는 상시 검색 가능해야하며(PCI DSS 1.2에서 변경된 항목임)
백업본은 1년 보관해야합니다.

로그 flow를 살펴보면 다음 단계를 거치게 됩니다.

1. 개별 OS, Application에서 네트웍 단위 로그서버로 로그 집중
2. 소단위 로그서버에서 중앙 로그서버로 로그 집중
3. 중앙 로그서버에서는 3개월까지 로그검색 가능해야함
4. 중앙 로그서버의 로그는 백업된다면 1년 보관.

Patch Management

소프트웨어 업데이트 또는 패치 관리는 Windows계열, Unix 계열으로 구분하여 대응이 필요합니다.

Windows 계열 OS인 경우 WSUS등이 우선 검토 대상입니다.

patch management가 중요하면서도 어려운 이유중 하나는

LAN구간의 서버들은 외부 인터넷과의 직접 접근이 엄격히 제한되는데
자동 패치를 위하여 서버들이 인터넷에 통상 접근하여 업데이트하는 방식과 상충됩니다.

DMZ구간등 외부 인터넷과 접근이 가능한 네트웍에 자동 업데이트를 위한 서버를 별도 운영할 필요성이 있습니다.

다행히 WSUS등은 그러한 요건에 대응이 됩니다.

Linux의 경우 YUM등을 통한 update를 하게 되는데
local server를 update server로 지정하여 처리하는 자동화된 방식에 있는지는
시간상 자세히 찾아보지 못하였습니다.

PCI DSS에서의 Requirement는 30일 이내에 업데이트하라는 것이며 Manual로 정기점검시 처리할수도 있습니다.
Linux의 update server 구성에 대해서는 코멘트 남겨주시면 확인후 반영하겠습니다.

GFI LANguard같은 제품이 windows OS auto update기능을 제공하기는 하는데 이 역시 internet access가 필요하여 사용에 제한이 있습니다.

Directory Server

Directory Server는 참 많은 곳에서 사용됩니다.

Windows 계열 OS에 대해서는 Active Directory가 절대적인 역할을 하며
이것으로
requirements 1.3.9 personal firewlal, 8.1~5까지의 요구사항을 직접적으로 충족할 수 있습니다.
그외에 AntiVirus 자동설치나 각종 접근제어등 Active Directory는 아주 요긴하게 사용됩니다.

Unix 계열로는 OpenLDAP이나 Sun Directory Server가 중요한 역할을 합니다.

각 vendor별로 directory server를 제공하는데
안정성이나 replication 기능등을 감안하여 신중하게 선택해야합니다.

요즘 Windows Active Directory에서도 Unix에 대한 지원이 강화되고 있어서
AD만으로 통합 인증을 시도해봄직하지만
상당히 많은 시도에서도 실패하여

현재 Windows계열은 AD, Unix 계열은 Sun Directory로 범위를 정하여 각종 패스워드 정책이나 Account Lockout정책을 반영하고 있습니다.

최신 Linux OS는 Active Directory Join이 가능하도록 지원하고 있으니 그 부분은 중점적으로 살펴볼필요가 있다.

참고로 Sun Directory는 Multi-master replication을 지원하는 최초의 제품으로 과거부터 사용해왔고
최초 20만 entry까지 무료 제공되다가 solaris9 OS에 기본 포함되면서 현재는 사용에 제약이 없는 상태입니다