2009년 12월 23일 수요일

순수웹환경에서의 전자금융 서비스 보안방안

순수웹환경에서의 전자금융 서비스 보안방안

ActiveX등의 Binary Plugin없이 순수웹(Pure Web)으로 전자금융서비스를 제공할 경우 어떤 보안대책이 필요할까
고민해보고 PCIDSS나 전자금융거래법 시행세칙등을 참조하여
최소한 아래와 같은 요구사항은 충족해줘야겠다는 생각이다.

이미 많은 기관들이 아래 보안요구사항들을 충족하고 있겠지만 확인하는 차원에서 한번더 정리해본다.

[순수웹환경에서의 전자금융서비스 보안]


1. 안전한 네트웍을 구축하고 유지

    1.1 방화벽을 설치하고 유지

        1.1.1 방화벽 구성 기준 수립

            - 변화관리 시스템 유지 (모든 설정변경사항을 승인하고 테스트하는 공식 절차가 존재해야함.)
            - 최신의 네트워크 구성도 유지
            - 인터넷과 내부 네트워크 사이에 DMZ Network 운용
            - 네트웍 구성요소에 대한 조직, 역할 및 책임을 정의
            - 모든 서비스, 프로토콜, 포트 사용에 대한 문서화 및 사용근거 명시
            - 안전하지 않은 프로토콜 사용시 이에 대한 보안대책 수립하고 문서화해야함.
            - 최소 6개월마다 룰셋 검토해야함.

        1.1.2 방화벽 및 라우터 구성

            - Inbound / Outbound 트래픽 제어
            - default deny rule
            - 라우터 설정파일의 보호 및 동기화
            - 무선네트워크와 내부시스템사이에 방화벽 설치

        1.1.3 내부 시스템에 대한 외부자의 직접접근 제한

            - 외부자의 이용가능한 프로토콜 제한
            - DMZ Network을 거치도록 네트웍 구성
                * 외부에서 Inbound traffic은 DMZ 내의 IP로 제한
                * 내부 시스템에서의 outbound traffic도 DMZ내의 IP로 제한
                * 필요시 forward / reverse Proxy 구성 운영
                * reverse proxy는 웹방화벽으로 대체가능
            - 방화벽에서는 Stateful Inspection을 적용 (이미 체결된 접속만을 네트워크로 허용)
            - Database는 DMZ으로부터 분리된 구간에 위치시킴
            - NAT나 PAT처럼 내부주소가 그대로 공개되지 않도록 주소변환 기술 이용

        1.1.4 개인방화벽 소프트웨어 설치 또는 활성화

            1.1.4.1 내부 사용자 시스템
                - 방화벽 설정은 회사에서 정한 표준규칙을 따라야함.
                - 개인이 임의로 방화벽 설정을 해제할 수 없도록 해야함.
            1.1.4.2 외부 사용자 시스템
                - 서버에서 사용자 개인 PC 환경을 직접 제어할 수 없다는 기본적인 사실 인지
                - 다양한 운영체제에 맞는 개인 방화벽 프로그램이나 활성화하는 방법을 자세하게 안내

    1.2 안전한 시스템 구성

        1.2.1 벤더제공 디폴트값 변경

            - SNMP Community String이나 기본 패스워드 등 변경
            - 무선환경에 대해서도 디폴트값 변경

        1.2.2 시스템 설정 기준 수립

            - 시스템 설정 기준은 알려진 모든 보안취약점에 대응하도록 수립되어야함.(SANS, NIST, CIS등 업계가 인정하는 보안강화 기준을 참조)
            - 서버당 하나의 주요 기능만을 구현
            - 불필요한 서비스나 프로토콜은 비활성화
            - 오용방지를 위한 시스템 보안 파라미터 설정
            - 스크립트, 드라이버, 기능, 하위시스템, 파일시스템, 불필요한 웹서버등 모든 불필요 기능 삭제

        1.2.3 모든 전송데이터에 대한 암호화

            - 콘솔 접근을 제회
            - SSH, VPN또는 SSL/TLS등의 기술을 이용

2. 고객정보 보호

    2.1 저장된 고객정보 보호

        2.1.1 고객 개인정보는 최소범위에서 저장

            - 법적, 제도적 요구사항을 감안하여 데이터 보유 및 폐기정책 수립
            - 데이터 보유 및 폐기정책에 따른 자동삭제 소프트웨어 구성

        2.1.2 중요한 개인인증 데이터를 저장하지 않음.

            - 중요 개인인증 데이터는 암호화 여부와 관계없이 저장하지 않음.
            - 중요 개인인증 데이터를 수신이후 삭제하는 경우 복구 불가능하게 데이터를 삭제해야함.

        2.1.3 중요 개인정보 출력시 마스킹 처리

            - 전체의 일부만 표시

        2.1.4 고객정보는 암호화하여 저장

            - 모든 로그파일에 개인정보가 존재하지 않아야함.
            - 백업매체 저장되는 경우도 암호화하여 저장해야함.
            - 모든 운용자 PC에 개인정보가 존재하지 않아야함.
            - 로그파일이나 개인PC에 개인정보가 존재하지 않음을 자동화된 프로그램으로 검증해야함.

        2.1.5 암호화에 사용된 암호화키는 안전하게 보호되어야함.

            - 암호화키에 대한 접근을 최소한의 관리자로 제한
            - 암호화키를 최소한의 장소와 형태로 안전하게 저장
            - 키관리 프로세스를 문서화하고 정해진 절차를 따라야함.
            - 암호화키는 강력한 보안비도로 생성
            - 암호화키는 안전한 과정을 거쳐 배포
            - 암호화키는 안전하게 저장되어야함.
            - 정기적으로 암호화키를 보호해야함.
            - 암호화키는 2인 이상에 의해 이중통제되어야함.
            - 암호화키는 승인받지 않고 교체될 수 없어야함.
            - 암호화키 관리자의 이해와 책임을 수용하는 동의서를 작성하고 비치해야함.

    2.2 공중망을 통한 고객정보 데이터 전송 암호화

        2.2.1 공중망의 범위

            - 인터넷
            - 무선기술을 이용한 네트웍 (GSM, CDMA, GPRS, WIFI, 기타)

        2.2.2 SSL/TLS, IPSEC등과 같은 보안 프로토콜을 사용해야함.

            - 강력한 보안비도의 Symmetric Algorithm이 사용되어야함.
            - 신뢰할 수 있는 CA인증서여야함.
            - SSLv3/TLSv1등 안전한 SSL Protocol을 사용해야함.
            - 사용자가 SSL 서버인증서와 도메인 및 사이트운영 기관을 명확히 확인할 수 있도록 EV(Extended Validation) SSL 서버 인증서를 이용

        2.2.3 안전한 무선네트워크 암호화 적용

            - WEP 사용 금지
            - IEEE 802.11i등 강력한 암호화 적용

        2.2.4 일반 사용자 메시징 기술을 통해 주요 고객정보 전송금지

            - E-Mail, Messenger, Chat등을 통해 고객정보 전송금지

3. 보안취약점 관리

    3.1 안티바이러스

        3.1.1 내부사용자

            - 운영자 PC에는 안티바이러스 소프트웨어를 적용
            - 바이러스 감염가능한 서버시스템에도 안티바이러스 소프트웨어 적용
            - 모든 시스템의 안티바이러스 적용여부를 확인할 수 있어야함.
            - 안티바이러스 감사 로그를 생성할 수 있어야한다.

        3.1.2 외부사용자

            - 서버에서 사용자 개인 PC환경을 직접 제어할 수 없다는 기본적인 사실에 인지
            - 다양한 운영체제에 맞는 안티바이러스 프로그램이나 활성화하는 방법을 자세하게 안내해야함.

    3.2 안전한 시스템과 어플리케이션을 개발하고 유지

        3.2.1 내부시스템

            - 모든 시스템과 소프트웨어에는 벤더제공 최신 보안 패치를 설치해야함.
            - 새로운 보안취약점을 식별하는 프로세스를 수립해야함.
            - 확인된 새로운 보안취약점에 대한 대응방안을 "시스템 설정기준" 문서에 반영해야함.

        3.2.2 외부 사용자 시스템

            - 서버에서 사용자 개인 PC환경을 직접 제어할 수 없다는 기본적인 사실 인지
            - 사용자 이용환경에 대한 보안패치 안내 
            - 사용자에게 보안업데이트이 중요성과 설치방법을 각 운영체제별로 충분히 안내
            - 윈도우 운영체제일 경우 OS Update나 KISA에서 제공하는 PC자동보안 업데이트 프로그램을 설치안내

    3.3 소프트웨어 개발 라이프사이클 전반에 걸쳐 정보보호 관련 사항을 통합해야함.

        3.3.1 반드시 운영시스템 적용전 테스트를 수행

            - 모든 입력값 검증테스트 수행
            - 적절한 에러처리 검증 테스트 수행
            - 안전한 암호화 저장 검증 테스트 수행
            - 안전한 커뮤니케이션 검증 테스트 수행
            - 적절한 역할기반 접근제어(RBAC) 검증 테스트 수행

        3.3.2 개발, 테스트 및 운영환경을 분리해야함.

        3.3.3 개발, 테스트 및 운영환경에 대한 직무를 분리해야함.

        3.3.4 운영데이터를 테스트나 개발을 위해 사용하지 않아야함.

        3.3.5 운영시스템 가동전 테스트트 데이터나 계정을 제거해야함.

        3.3.6 어플리케이션 가동전, 고객배포전 개발계정, 사용자ID, 임시 패스워드 제거해야함.

        3.3.7 제3자에 의한 개발코드 리뷰를 거쳐야함.

            - 코드 작성자 외의 제3자에 의한 코드리뷰가 필요
            - 코드 리뷰 결과는 경영층에 의해 검토되고 승인되어야함.
            - 코드 리뷰시 OWASP와 같은 코딩 지침에 따라 개발되었는지 검토해야함.

    3.4 변경관리절차에 따라 시스템 구성요소 변경

        - 변경의 영향에 대한 문서화
        - 적합한 관리자의 승인
        - 운영기능 테스트
        - 복귀(Back-out) 절차

    3.5 OWASP 취약점 대응

        - 크로스사이트 스크립팅(XSS) 대응
        - SQL Injection등 Injection 오류에 대응
        - 사용자가 어플리케이션에 실행가능한 악성파일을 올릴 수 없고 실행되지 않도록 악성파일 실행을 방지해야함.
        - 시스템 내부 Object를 사용자에게 노출하지 않도록 불안전한 직접 객체 참조 방지
        - 크로스 사이트 요청변조(CSRF) 방지
        - 오류 메세지등에서 주요정보가 유출되지 않도록 정보유출과 부적절한 에러처리 방지지
        - 취약한 인증 및 세션관리 방지
        - 불안전한 암호화 저장 방지
        - 모든 인증과 민감한 통신에 적절한 암호화를 적용하여 불안전한 통신을 예방
        - URL접근통제 실패 대응
        - 기타 OWASP version별 보안취약점에 대하여 대응해야함.

    3.6 웹어플리케이션 보호

        - 정기적으로 자동화된 웹어플리케이션 취약점 보안측정 도구 혹은 방법으로 취약점 검토
        - 웹방화벽 설치

    3.7 Anti keylogger

        - 사용자 개인 PC가 침해되었더라도 전자금융거래에 필요한 최소한의 보안성을 확보하기 위해 키보드 해킹방지 솔루션 적용할 수 있음.
        - 자바스크립트 기반의 "Onscreen Keyboard"를 이용하여 사용자가 키 입력을 하지 않도록 유도
        - 키 배열은 세션별로 Random하게 배치

    3.8 자바스크립트 보안

        - 자바스크립트의 무결성(Integrity)를 확인할 수 있는 체계를 수립하여 적용
        - 자바스크립트 난독기(Obfuscation)을 적용할 수 있음.
        - 자바스크립트의 일부를 서버에서 필요시 동적으로 로딩하여 사용
        - 자바스크립트의 주요 소스를 세션정보와 연계하여 Static하게 재사용 불가하도록 구성

    3.9 피싱방지를 위한 조치

        - 사용자 아이디 입력 페이지와 로그인 페이지를 순차로 배치하고
        - 로그인 페이지에서 해당 사용자가 미리 선택한 seal이나 site key아이콘이 뚜력이 드러나도록 설계한다.
        - 서버가 EV SSL 인증서를 채택하는 경우 사용자들이 EV SSL 인증서 채택 서버에 접속해 있음을 확인하고 
        - 로그인 정보를 입력하도록 해당 정보 입력란 근처에 설명, 안내한다.
        - 사용자의 명시적 요청이 없는한 서버가 사용자에게 명세서, 기타 안내 메일을 보내지 않는다.

    3.10 부인방지

        3.10.1 사전 약정에 의한 부인방지 효력 부여

            - 부인방지 효력은 오프라인 서명이나 인감날인 및 온라인 공인 전자서명으로 발생됨
            - 사전 약정과정에서 온라인에서 특정 인증정보 사용시 부인방지효력을 명시하고 동의받음.
            - 특정 인증정보는 아래와 같은 사항을 고려한다.
                * OTP 인증코드사용
                * 이체 비밀번호 사용
                * 로그인 비밀번호 재입력
                * 기타 플랫폼 독립적인 별도 방식 이용

        3.10.2 기술적 부인방지

            - 계좌이체와 같은 금융거래시 악성 코드의 Form데이터 조작에 의해 사용자의 보안빙자 자체에 위해가 가해질 수 있음.
            - 공격에 의한 데이터 조작으로 부인방지 효력상실을 방지하기 위한 기술적 절차적 수단을 강구한다.
                * 실시간 수행하지 않고 시차를 두어 Queue에 쌓아둔 후 사용자에 의한 추심 인증이 있을때 거래를 승인한다.

        3.10.3 추심인증

            - 일정조건의 거래에 대해서 사용자가 접속한것과 다른 채널 (SMS, OTP, 전화 등)을 통해서 2차 인증하는 정책을 유지해야함.

4. 강력한 접근통제

    4.1 업무상 알 필요가 있는지에 따라 개인정보 접근제한

        4.1.1 해당 데이터가 필요한 직원에게만 접근 허용

            - 사용자 ID는 직무수행에 필요한 최소권한으로 제한
            - 권한할당은 직원의 직무분류와 기능을 근거로
            - 공식적인 관리자의 승인절차를 거침
            - 자동화된 접근통제 시스템의 구현

        4.1.2 Default Deny 접근통제 정책 설정

            - 모든 시스템 구성요소를 포함
            - 직무분류와 기능을 기준으로 개인별 권한 할당

    4.2 사용자별 고유 ID 부여

        4.2.1 시스템에 접근하는 모든 사용자에게는 사용자를 구분할 수 있는 고유 ID를 발급해야함.

        4.2.2 고유ID는 패스워드등 추가 인증방식으로 사용자를 인증해야함.

        4.2.3 원격 접속시 2-Factors 인증 적용해야함.

        4.2.4 모든 패스워드에 대해서 강력한 암호화를 적용해야함.

        4.2.5 공식적인 사용자 인증 및 패스워드 통제절차를 마련해야함.

            - 사용자의 추가, 삭제, 수정에 대한 통제절차를 마련해야함.
            - 패스워드 재설정전 사용자 신원확인
            - 초기설정 패스워드는 즉시 변경 유도
            - 퇴사/ 탈퇴시 접근권한 즉시 말소
            - 최소 90일마다 미사용 사용자 계정 재거 또는 정지
            - 원격유지보수를 위한 계정은 일정시간만 사용가능하게 설정
            - 모든 사용자에게 패스워드 절차와 정책 배포
            - 공용 패스워드사용 금지
            - 패스워드는 90일마다 변경
            - 최소 7자리의 패스워드 자릿수 
            - 영문과 숫자를 포함한 복잡한 패스워드 사용
            - 과거 4회까지의 패스워드 재사용금지
            - 6번이상 접근실패시 사용자 계정 자동잠금
            - 계정잠금시 최소 30분간은 유지
            - 세션이 15분이상 Idle상태인 경우 자동 Timeout
            - 데이터베이스에 대한 접근통제 포함

        4.2.6 외부 사용자에 대한 두가지 이상 요소로 사용자 인증

            - 명확하고 안전하게 사용자 인증을 하기 위ㅐ서 최소한 2가지 이상의 방식을 복합하여 사용자 인증을 수행
            - 복합 사용가능한 인증요소로 다음사항을 고려
                * 패스워드 (조회 또는 이체에 복수 사용 가능)
                * 일회용 암호 생성기(OTP) 혹은 모바일 OTP 소프트웨어
                * 모바일 SMS 인증
                * SSL Client Authentification하의 공인인증서 로그인
            - 위 인증방식들을 제시하고 이중 사용자가 2개 이상을 복합적으로 선택하여 인증을 수행할 수 있도록 제공

    4.3 물리적 접근통제

        4.3.1 적절한 출입통제 사용

            - DVR등을 통한 감시
            - 네트웍 잭에 대한 접근통제
            - 무선 AP에 대한 접근통제
            - 휴대용 장비에 대한 접근통제

        4.3.2 직원과 방문자 식별절차 마련

        4.3.3 모든 방문자에 대한 적절한 통제

        4.3.4 방문자 활동기록 보관

        4.3.5 안전한 백업매체 보관

        4.3.6 개인정보를 포함한 종이 및 물리적 전자매체에 대한 보호

            - 해당 매체가 기밀로 식별되도록 분류
            - 이동시 추적가능한 안전한 방법으로 전달
            - 이동에 대한 관리자 승인

        4.3.7 개인정보를 담고 있는 저장소나 매체에 대한 엄격한 접근통제

            - 매체목록을 유지하고 연 1회 재고조사

        4.3.8 불필요 정보에 대한 적절한 파기

            - 복구불가능한 방법으로 파기한다.
            - 종이 분쇄기 이용
            - 전자매체에 대한 DeGausser이용 파기

5. 모니터링 및 테스트

    5.1 모든 접근을 추적하고 감시

        5.1.1 모든 접근시도에 대한 개별 사용자 연관 프로세스 수립

        5.1.2 자동화된 감사추적기능 구현

            - 사용자 식별
            - 이벤트 종류
            - 날짜와 시간
            - 성공 혹은 실패 표시
            - 이벤트의 시작지점
            - 영향받는 데이터, 시스템 구성요소 또는 자원으 신원 또는 이름

        5.1.3 시간동기화 설정

        5.1.4 감사기록에 대한 무결정(Integrity) 보호

        5.1.5 모든 로그에 대한 일일 점검

        5.1.6 로그기록은 최소 1년간 보관


    5.2 보안시스템 및 프로세스에 대한 정기적 시험

        5.2.1 분기별 1회 무선보안 취약점 시험

        5.2.2 정기적 네트웍 취약점 스캐닝

            - 최소 분기별 1회
            - 내부 및 외부 취약점 스캐닝

        5.2.3 정기적 침투시험

            - 내부 및 외부 네트워크 계층 침투 시험
            - 내부 및 외부 어플리케이션 계층 침투 시험
            - 침투시험시 알려진 모든 해킹기법을 이용한 침투 시험실시

        5.2.4 IDS/IPS를 이용하여 시스템 보호

        5.2.5 시스템 파일 무결성(Integrity) 감시 소프트웨어 운용용


6. 보안정책관리

    6.1 정보보호 정책의 수립, 공표, 유지관리 및 배포

        - 여기서 언급되는 모든 보안요구사항이 다루어져야함.
        - 위협과 취약점을 파악하고 공식적인 위험평가를 수행하는 연간 프로세스가 포함되어야함.
        - 최소한 매년 검토되어야함.

    6.2 일일 보안점검 절차 수립

    6.3 직원들이 사용하는 중요한 기술들에 대한 사용정책 제정

        - 사용에 대한 명시적 관리자 승인
        - 기술사용에 대한 인증
        - 장비목록과 사용자 목록 유지
        - 소유자, 연락처, 사용목적이 명시된 라벨링
        - 해당기술의 합당한 사용
        - 해당기술에 대한 네트워크상의 합당한 위치
        - 회사가 승인한 제품 목록
        - 특정 시간동안 활동이 없을 경우 자동 세션 종료
        - 벤더에 의한 운격접근기술은 필요시만 이용하고 사용후 즉시 구동중지
        - 원격접근시 데이터 복사, 이동, 저장 금지

    6.4 모든 직원과 계약업체의 정보보호 관련 책임을 명확히 규정

    6.5 직원 또는 팀에게 정보보호 관리 책임 할당

        - 정보보호 정책과 절차의 수립, 문서화 및 배포 책임
        - 보안경고 및 정보 감시/분석하고 적절한 인력에게 배포하는 책임
        - 보안사고 대응 및 보고절차를 수립/문서화/배포 책임
        - 사용자 계정 관리 책임
        - 데이터 접근 감시 및 통제 책임

    6.6 정보보호 중요성을 인식할 수 있는 공식적인 보안인식 프로그램 이행

    6.7 직원고용이전 적격 심사 수행

    6.8 외부 서비스 업체와의 상호연동을 위한 정책과 절차를 유지하고 이행

    6.9 침해사고 대응계획 수립

2009년 12월 22일 화요일

한국형 전자상거래 서비스 제공자간 상호연동 표준안(KECIS)

한국형 전자상거래 서비스 제공자간 상호연동 표준안

Korea Electronic Commerce Interoperability Standard

(분산환경에서 서비스 제공자들간의 상호 연계를 위한 데이터 송수신 표준 구조)




1. KECIS가 왜 필요한가?

- 다양한 서비스 제공자간의 표준화된 데이터 송수신 "방법" 부재
- 다양한 서비스 제공자간의 표준화된 데이터 송수신 "구조" 부재
- 위 "부재"로 인해 서비스 연동을 위한 중복된 Resource 소모, 복합적인 서비스 연계 불가

- 유저가 쇼핑몰(Shopping Service Provider)에 접근하는 경우
- 공급자는 유저에 대하여는 자신의 방식으로 서비스를 제공한다.
- 공급자는 자신과 전용으로 연결되어 있는 각각의 서비스 제공자와 별도 연결.


==> 각 공급자간의 표준 데이터 송수신 방법 부재

- 분산환경하의 결제서비스 공급자(Payment Service Provider)를 포함한 다수의 공급자들(Providers)이 자유롭게 결제및 인증 구조에 참여할 수 있는 표준화된 데이터 송수신 구조 확립이 필요

1.1 ECML을 이용한 구조 표준화

- XML Encryption으로 데이터 암복호화
- XML Signature으로 데이터 전자서명/서명검증
- 공인인증 인프라 이용

1.2 SAML이용하여 송수신 방법 표준화





2. KECIS는 누구에게 필요한가?

2.1 분산환경에서의 다양한 공급자들


다양한 형태의 서비스 공급자들이 인터넷 상이 존재한다.

- 쇼핑몰 서비스 공급자

- 신용카드 결제서비스 공급자

- 휴대폰 결제서비스 공급자

- 계좌이체 결제서비스 공급자

- 공인인증 인증서비스 공급자

- i-PIN 인증서비스 공급자

- OpenID 인증 서비스 공급자

- 배송서비스 공급자

- 문자발송서비스 공급자


이 공급자들은 나름의 방법으로 서비스를 유저에게 제공


3. KECIS에서는 공급자들간 무엇을 주고받는가?

3.1 K-ECML 포맷의 XML Message

3.1.1 ECML (Electronic Commerce Modeling Language)

- ECML v1 by RFC2706 at 1999
- ECML v1.1 by RFC3106 at 2001
- ECML v2.0 by RFC4112 at Jun/2005
- IETF에서 기술적인 개발 및 변경관리 수행

3.1.2 K-ECML as ECML addon

- 국내 카드사 코드 추가
- 국내 카드거래 종류 추가 (금액인증, ISP, 안심클릭 등)
- 국내 결제수단 추가 (계좌이체, 휴대폰 결제, 가상계좌 입금통지 등)

3.2 K-ECML Field List

4. KECIS에서는 공급자들간 어떻게 데이터를 주고받는가?

4.1 SAML 이용

- SAML의 데이터 송수신 구조 응용
- 유저 브라우저가 데이터 송수신의 라우터 역할을 함.

4.1.1 SAML Use Case Diagram


- Google Login with SAML

4.2 KECIS의 SAML 응용 데이터 흐름도


4.3 이용자와 다수의 공급자


각 공급자는 기존의 존재하는 자신만의 방식으로 그대로 서비스를 제공하면서
다른 서비스 제공자와 서비스 결과를 표준화된 방식으로 주고받을 수 있다면

하나의 공급자가 모든 서비스를 묶어서 힘들게 제공할 필요없이

자신이 가장 잘하는 서비스를 집중하여 유저에게 제공하며
자신이 보유하고 있지 않은 서비스를 해당 서비스 공급자에게 표준적인 방법으로 요청(*)하고
그 결과를 역시 표준적인 방법으로 응답받아 확인(*) 하고
다음 프로세스를 진행할 수 있다.




각 공급자간의 데이터 송수신은 XML Message를 기반으로 하며

공급자의 공인인증서로 상호 XML 전자서명 - 서명검증 하거나
XML 암호화 - 복호화 하여 데이터를 주고받으며
주고받는 데이터의 구조는 XML Schema 표준에 의하여 정의한다.

4.4 다수 공급자간의 Use Case Diagram









5. KECIS는 구현되어 있는가?

5.1 오픈소스로 공개되어 있음.


5.2 KECI Public Server

- java daemon
- 공인인증 Public Key만을 Handling
- XML Request Message에 대한 공인인증 공개키 암호화
- XML Response Message에 대한 공인 전자서명 검증
- Public Key에 대한 CRL checking

5.3 KECI Private Server

- java daemon
- 공인인증 Public & Private Key pair handling
- 공인인증 Private Key의 HSM 보관을 위한 Interface
- KECI Public Server의 모든 기능 포함
- XML Encryption / Decryption
- XML Signature / Verification

5.4 client Libraries

- JSP로 구현
- KECI Public Server와 TCP/IP Socket 통신
- K-ECML XML Message 생성 / 파싱
- DOM Communication을 위한 javascript library 포함

6. KECIS구조하의 상호연동 시나리오

6.1 2곳의 서비스 제공자간 상호연동 시나리오

6.1.1 상점과 결제대행사

머천트
    • 머천트는 고객이 상품선택을 완료하면
    • K-ECML formatXML Message 생성
    • KECI Public Server를 통해 결제대행사의 공인인증서로 요청정보 암호화
    • 유저 브라우저를 통해 해당 요청정보를 결제대행사로 전송

결제대행사
    • 결제대행사에서는 요청정보를 공인인증서의 개인키로 복호화
    • 고유한 프로세스로 결제처리
    • 결제결과를 KECI Private Server를 이용하여 전자서명
    • 서명된 메세지를 유저 브라우저를 이용하여 전송

머천트
    • 결제대행사에서 유저브라우저를 거처 전송해온 정보 수신
    • KECI Public Server를 이용하여 서명 검증
    • 결제가 완료된것을 확인한 머천트는 유저에게 상품 제공

6.1.2 상점과 은행

상점
    • 고객이 상점의 상품 선택
    • KECI client library를 이용하여 K-ECML XML Message 생성
    • 생성된 K-ECML Message를 KECI Public Server로 암호화
    • 암호화된 "요청" 메세지를 은행으로 전송

은행
    • 유저 브라우저를 거쳐 암호화된 메세지 수신
    • KECI Private Server를 통해 해당 메세지 복호화
    • 은행 웹사이트내에서 계좌이체 진행
    • 계좌이체 결과를 KECI Private Server로 전자서명
    • 서명된 메세지를 유저 브라우저를 통해 상점으로 전송

상점
    • 은행에서 유저 브라우저를 거쳐 전송되어온 서명된 메세지 수신
    • KECI Public Server통해 공인 전자서명 검증
    • 계좌이체가 완료된것을 확인후 유저에게 상품 제공

6.2 n개의 서비스 제공자간

6.2.1 상점, 은행, 공인인증기관

상점
    • 고객이 상품 선택
    • KECI Public Server로 요청정보 암호화
    • 유저브라우저 통해 은행으로 계좌이체 요청 전송

은행
    • 암호화 메세지 수신
    • KECI Private Server통해 정보 복호화
    • 계좌이체 시작
    • 본인확인을 위해 본인확인 요청 정보 KECI Public Server통해 암호화
    • 공인인증기관으로 전송

공인인증기관
    • 본인확인 요청 접수
    • 공인인증기관 웹사이트에서 유저와 본인확인 진행
    • 본인확인결과를 KECI Private Server로 전자서명
    • 은행으로 본인확인 결과 전달

은행
    • 전자서명된 본인확인 정보 수신
    • 계좌이체 처리
    • 계좌이체 처리완료 정보를 KECI Private Server로 전자서명
    • 유저브라우저를 통해 상점으로 이체결과 전송

상점
    • 계좌이체 결과 수신
    • KECI Public Server로 서명검증
    • 유저에게 상품제공

6.2.2 n개의 서비스 제공자들

  • 암호화된 요청정보 수신
  • KECI Private Server로 데이터 복호화
  • 서비스 제공자의 고유한 서비스 제공
  • 서비스 제공 결과를 KECI Private Server통해 전자서명
  • 전자서명된 결과를 원 요청자에게 응답

7. References

7.1 ECML


7.2 SAML

http://blog.sdnkorea.com/blog/501 : SAML을 이용한 SSO 구현

7.3 XML Encryption


7.4 XMLDSIG


8. 작성자

이동산 (Mountie Lee)
mountie@paygate.net