[공공데이터]
과학기술정보통신부 국립전파연구원_방송통신표준_개체 인증 보증 프레임워크
이 표준은 주어진 상황에서 개체 인증 보증을 관리하기 위한 프레임워크를 제공한다. 특히 이것은,
- 개체 인증 보증의 4개 수준을 명시한다.
- 개체 인증 보증의 각 4개 수준을 달성하기 위한 기준과 지침을 명시한다.
- 4단계의 LoA에 기초한 인증의 결과를 교환하기 위한 지침을 제공한다.
- 인증 위협을 완화하기 위해 사용되어야 하는 통제에 관한 지침을 제공한다.
■ 관련 데이터
| 개체 인증 보증 프레임워크 KS X ITUT X1254:2012 |
방 송 통 신 표 준 심 의 회
2017년 12월 27일 제정
목 차
4.7 4-수준의 LoA에 기초하여 교환된 인증 결과.. 8
8.2 크리덴셜 관리 단계에 대한 위협 및 통제.. 19
머 리 말
이 표준은 방송통신발전기본법 관련 규정에 따라 방송통신표준심의회의 심의를 거쳐 제정한 방송통신표준이다.
이 표준은 저작권법에서 보호 대상이 되는 저작물이다.
이 표준의 일부가 기술적 성질을 가진 특허권, 출원공개 이후의 특허출원, 실용신안권 또는 출원공개 후의 실용신안등록출원에 저촉될 가능성이 있다는 것에 주의를 환기한다. 관계 중앙행정기관의 장과 방송통신표준심의회는 이러한 기술적 성질을 가진 특허권, 출원공개 이후의 특허출원, 실용신안권 또는 출원공개 후의 실용신안등록출원에 관계되는 확인에 대하여 책임을 지지 않는다.
개 요
이 표준은 2012년에 발행된 ITU-T X.1254 Entity authentication assurance framework를 기초로 기술적인 내용 및 대응국제표준의 구성을 변경하지 않고 작성한 방송통신표준이다.
방송통신표준
KS X ITUT X1254:2012
| 개체 인증 보증 프레임워크 |
| Entity authentication assurance framework |
1 적용범위
이 표준은 주어진 상황에서 개체 인증 보증을 관리하기 위한 프레임워크를 제공한다. 특히 이것은
— 개체 인증 보증의 4 개 수준을 명시한다.
— 개체 인증 보증의 각 4 개 수준을 달성하기 위한 기준과 지침을 명시한다
— 4단계의 LoA에 기초한 인증의 결과를 교환하기 위한 지침을 제공한다.
— 인증 위협을 완화하기 위해 사용되어야 하는 통제에 관한 지침을 제공한다
2 인용표준
해당사항 없음
3 용어와 정의 및 약어
이 표준의 목적을 위하여 다음의 용어와 정의 및 약어를 적용한다.
3.1 용어와 정의
3.1.1
주장(assertion) [b-ITU-T X.1252]
개체가 제기하는 내용으로서 그 타당성의 증거가 제시되지 않은 것
비고 제기(claim)와 주장(assertion) 용어의 뜻은 일반적으로 어느 정도 유사하지만 약간 다르다고 합의되었다. 이 표준에서는 주장(assertion)은 제기(claim)보다 더 강한 선언으로 간주한다.
3.1.2
인증(authentication) [b-ISO/IEC 18014-2]
개체의 신원에 대한 보증의 제공
3.1.3
인증 요소(authentication factor) [b-ISO/IEC 19790]
인증 또는 개체의 신원을 검증하는데 사용되는 정보의 조각 및/또는 프로세스
비고 인증 요소는 4개 카테고리로 나뉜다.
— 개체가 가지고 있는 것(예, 장비 서명, 여권, 크리덴셜을 저장한 하드웨어 장비, 개인키)
— 개체가 알고 있는 것 (예, 패스워드, PIN)
— 개체 자체(예, 생체 특성)
— 개체가 전형적으로 수행하는 것(예, 활동 패턴)
3.1.4
제기(claim) [b-ITU-T X.1252]
증명할 수 없음에도 그러함을 선언하는 것.
3.1.5
상황(context) [b-ITU-T X.1252]
개체가 그 안에서 존재하고 상호작용하는 정의된 경계 조건을 갖는 환경
3.1.6
크리덴셜(credential) [b-ITU-T X.1252]
제기된 신원 또는 자격의 증거로서 제시된 데이터의 집합
3.1.7
개체(entity) [b-ITU-T X.1252]
상황 내에서 식별될 수 있는 분리된 별개의 존재
비고 이 표준의 목적에 따라 개체는 또한 신원을 제기하고 있는 자에 대한 구체적인 사례에서 사용될 수 있다.
3.1.8
신원(identity) [b-ISO/IEC 24760]
개체에 관련된 속성 집합
3.1.9
다중요소 인증(multi-factor authentication) [b-ISO/IEC 19790]
최소 두 개의 독립적인 인증 요소를 갖는 인증
3.1.10
부인방지(non-repudiation) [b-ITU-T X.1252]
활동의 전부 또는 일부에 참여했던 관련 개체 중 하나의 부인에 대한 보호 능력
3.1.11
부인(repudiation) [b-ITU-T X.1252]
관련된 개체 중 하나가 활동의 전부 또는 일부에 참가 했던 사실을 부인하는 것
3.1.12
인증 프로토콜(authentication protocol)
개체와 검증자 간에 주고 받는, 검증자가 개체를 인증할 수 있도록 정의된 연속적인 메시지들
3.1.13
권위있는 출처(authoritative source)
정확한 최신의 정보 원천으로 간주되는 저장소
3.1.14
크리덴셜 서비스 제공자(credential service provider, CSP)
크리덴셜을 발행하거나 관리하는, 또는 둘다 수행하는 신뢰대상자
3.1.15
개체 인증 보증 (entity authentication assurance, EAA)
개체가 무엇인지 또는 기대되는 개체가 인증 과정에서 도달하는 확신 정도 (이 정의는 [b-ITU-T X.1252]에서 주어진 ‘인증 보증’의 정의에 기초한다)
비고 신뢰는 개체와 그 제시된 신원 간의 연결에 대한 신뢰의 정도에 기초한다.
3.1.16
식별자(identifier)
특정 상황에서 개체를 유일하게 특징지우는 하나 또는 그 이상의 속성
3.1.17
신원 정보 검증(identity information verification)
진정성(authenticity), 타당성(validity), 정확성 및 개체에 대한 바인딩의 관점에서 발행자, 데이터 원천 또는 기타 내외부 자원들에 대하여 신원 정보와 크리덴셜을 검사하는 프로세스
3.1.18
신원 검증(identity proofing)
등록 기관(registration authorigy, RA)이 개체를 식별하기 위하여 특정한 또는 이해할 수 있는 보증 수준에 이르기까지 충분한 정보를 수집하고 검증하는 프로세스
3.1.19
중간자 공격(man-in-the-middle attack)
공격자가 두 당사자 간의 메시지를 몰래 읽고, 쓰고, 수정할 수 있는 공격
3.1.20
상호 인증(mutual authentication)
양자의 개체에게 각자의 신원에 대한 보증을 제공하는 신원 인증
3.1.21
피싱(phishing)
전자우편 사용자를 속여 개인 또는 기밀 정보를 노출하게 만들고도록 하고 이를 불법적으로 이용하는 신용 사기
3.1.22
등록 기관(registration authority, RA)
개체의 신원에 대한 크리덴셜 서비스 제공자에게 수립 혹은/및 보증을 하는 신뢰받는 행위자
3.1.23
신뢰당사자(relying party, RP)
신원의 주장 또는 제기에 의지하는 자
3.1.24
솔트(salt)
해쉬 프로세스에서 사용되는 종종 임의로 정해지는 비밀이 아닌 값
비고 이것은 샌드(sand)로도 불린다.
3.1.25
공유 비밀(shared secret)
개체와 검증자만이 알고 있는 인증에 사용되는 비밀
3.1.26
타임 스탬프(time stamp)
공통의 참조에 대하여 어떤 시점을 표시하는 신뢰할 수 있는 시간의 변이 파라미터
3.1.27
트랜잭션(transaction)
업무 또는 프로그램적 목적을 지원하는, 개체와 서비스 제공자간의 별개의(descrete) 사건
3.1.28
신뢰 프레임워크(trust framework)
신원 정보를 교환하는 당사자들을 위한 요구사항 및 강제 메커니즘의 집합
3.1.29
신뢰할 수 있는 제3자(trusted third party, TTP)
지정된 활동에 대하여(예, 보안관련 활동) 다른 행위자에게 신뢰받는 기관 혹은 대리인
비고 신뢰할 수 있는 제3자는 인증을 목적으로 하는 개체 및/또는 검증자의 신임을 받는다.
3.1.30
유효 기간(validity period)
하나 혹은 그 이상의 거래에서 사용되는 신원 혹은 크리덴셜의 기간
3.1.31
검증(verification)
제공된 정보를 이전의 확증된 정보와 비교함으로써 정보를 확인하는 프로세스
3.1.32
검증자(verifier)
신원 정보를 확증하는 행위자
비고 검증자는 개체 인증 보증 프레임워크(EAAF)의 다수의 단계에 참여할 수 있고, 크리덴셜 검증및/혹은 신원정보 검증을 수행할 수 있다.
3.2 약어
CA Certification Authority
CSP Credential Service Provider
EAA Entity Authentication Assurance
EAAF Entity Authentication Assurance Framework
ICT Information and Communication Technology
IdM Identity Management
IP Internet Protocol
LoA Level of Assurance
LoAs Levels of Assurance
MAC Media Access Control
NPE Non-Person Entity
PDA Personal Digital Assistant
PII Personally Identifiable Information
PIN Personal Identification Number
RA Regsitration Authority
RP Relying Party
SAML Security Assertion Markup Language
TCP/IP Transmission Control Protocol/Internet Protocol
TLS Transport Layer Security
TPM Trusted Platform Module
TTP Trusted Third Party
URL Uniform Resource Locator
4 보증의 수준
이 개체 인증 보증 프레임워크(EAAF)는 개체 인증을 위해 4 단계의 보증 수준을(LoA)을 정의한다. 각 보증 수준은 인증 과정 그 자체를 포함하며 그 과정에서의 신뢰의 정도를 표현한다. 즉, 특정한 신원을 사용하는 개체가 실제로 그 신원이 할당된 개체라는 것을 보장한다. 이 표준의 의도에 따르면, LoA는 8 절에서 설정된 기준에 기초한 EAAF의 각 단계를 위해 크리덴셜 서비스 제공자가 구현한 프로세스, 관리 활동, 기술적 통제들의 함수이다. 개체 인증 보증(EAA)은 관리 고려사항과 조직 고려사항의 영향을 받으나, 이 표준은 그러한 고려사항을 위한 명확한 규범적 기준을 제공하지 않는다. 개체는 사람일수도 있고, 사람이 아닌 개체(NPE, non-person entity)일 수도 있다.
예를 들어, 네트워크의 보증 수준은 네트워크를 구성하는 모든 요소의 보증 수준의 함수일 수 있고, NPE나 단말 장비(예, 핸드폰, PDA, 셋톱박스, 노트북 등)를 포함한다. 일부 경우에는, 단말 장비는 합당한 개체인 척 가장할 수 있다. 결과적으로 주어진 신뢰 수준에 따라 신뢰할 수 있는 장비를 그렇지 않은 장비와 구분하는 능력은 EAA에 있어 필수적이다.
이 표준에서 LoA1은 가장 낮은 단계의 보증을, LoA4은 가장 높은 단계의 보증을 나타낸다. 주어진 상황에 따라 어떤 LoA가 적합한지 결정하는 것은 여러 요소에 의해 좌우된다. 필수 LoA의 결정은 주로 인증 오류의 결과 및/혹은 크리덴셜의 오용, 그에 따른 피해와 영향, 발생의 가능성 등과 같은 위험에 기초한다. 높은 LoA는 높게 인지되는 위험에 사용해야만 한다.
EAAF는 4가지 LoA의 각 단계별 요구사항과 구현 지침을 제공한다. 특히 EAAF는 다음 단계들을 위한 프로세스 구현 요구사항을 제공한다.
a) 등록(enrolment) (예, 신원검증, 신원 정보 검증, 등록(registration))
b) 크리덴셜 관리(credential management) (예, 크리덴셜 발행, 크리덴셜 실행)
c) 인증
이는 개체 인증 보증에 영향을 끼치는 관리 고려사항과 조직 고려사항(예, 법적 준수, 정보 보호 관리)에 대한 안내 또한 제공한다.
아래 표 1에 LoA를 정의하였다.
표 1 — 보증의 수준
| 수준 | 정의 |
| 1 – 낮음(Low) | 제기 또는 주장하는 신원에 신뢰가 적거나 없음 |
| 2 – 중간(Medium) | 제기 또는 주장하는 신원에 약간의 신뢰가 있음 |
| 3 – 높음(High) | 제기 또는 주장하는 신원에 높은 신뢰가 있음 |
| 4 – 매우 높음(Very high) | 제기 또는 주장하는 신원에 매우 높은 신뢰가 있음 |
이 프레임워크에는 개체 인증 보증 프레임워크의 각 단계에 대하여 원하는 LoA를 달성하기 위한 요구사항이 포함되었다. 이 프레임워크를 구현하여 달성하게 되는 종합 LoA는 가장 낮은 LoA 단계의 수준이 될 것이다.
4.1 보증 수준 1(LoA1)
LoA1에서 개체가 제기 또는 주장하는 신원에 대해 최소한의 신뢰가 존재한다. 이것은 연속된 인증 사건에 걸쳐 그 개체가 동일하다는 정도의 신뢰이다. 이 LoA는 잘못된 인증에 관련된 위험이 낮을 때 사용된다. 사용되는 인증 메커니즘에 대한 구체적인 요구사항은 없다. 오로지 최소한의 보증만이 제공된다. 더 높은 LoA와 관련된 크리덴셜을 포함한 사용가능한 다양한 기술들이 이 LoA를 위한 개체 인증 보증 요구사항을 만족시킬 수 있다. 이 수준에서는 암호화된 인증 방법(예, 도전-응답 인증 프로토콜(cryptographic-based challenge-response protocol)을 요구하지 않는다.
예를 들어, LoA1은 사용자 맞춤 페이지를 생성하는 서비스 제공자의 웹사이트에 개체가 직접 등록한 사용자 명 혹은 비밀번호를 제출할 때, 또는 뉴스나 제품 문서와 같은 자료나 문서에 접근하기 위해 등록이 필요한 웹사이트에서의 거래 시의 인증에 적용할 수 있다.
예를 들어 LoA1에서는, 매체접근제어(MAC) 주소가 장치 인증 요구사항을 만족시킬 수도 있다. 그러나 다른 장치가 같은 MAC주소를 사용하지 못한다고 확신할 수 없다.
4.2 보증 수준 2(LoA2)
LoA2에서는 개체가 제기 또는 주장하는 신원에 대해 약간의 신뢰가 있다. 이 LoA는 잘못된 인증에 관련된 위험이 중간 정도일 때 사용된다. 단일 요소 인증이 수용된다. 성공적인 인증은 안전한 인증 프로토콜(secure authentication protocol)을 통해 크리덴셜에 대한 개체의 통제력을 확인하는 개체 검증에 좌우하여야만 한다. 도청 및 온라인 추측 공격의 효과를 감소시키기 위한 통제가 존재해야 한다. 저장된 크리덴셜을 공격으로부터 보호하기 위한 통제가 존재해야만 한다.
예를 들어, 서비스 제공자는 고객이 자신의 주소를 스스로 변경할 수 있게 하는 웹사이트를 운영할 수 있다. 수령인이 자신의 주소를 바꾸는 거래는, 중간 정도의 불편에 연관될 수 있으므로 LoA2 인증 거래로 볼 수도 있다. 납입금, 계정 상태, 그리고 변경 기록에 관한 공시는 주로 수령자의 주소로 보내지기 때문에, 이 거래는 개인 식별 정보(PII)의 인가되지 않은 유출과 같은 중간 정도의 위험을 수반한다. 그 결과로, 이런 거래가 이루어지기 전에, 서비스 제공자는 최소한 어느 정도의 인증 보증을 갖추어야 한다.
4.3 보증 수준 3(LoA3)
LoA3에서는 개체가 제기 또는 주장하는 신원에 대해 높은 신뢰가 있다. 이 LoA는 잘못된 인증에 관련된 위험이 높을 때 사용된다. 인증 프로토콜 내에서 교환된 모든 비밀정보는 송신 중에나 저장될 때 암호로 보호되어야만 한다(LoA3 암호기반의 도전-응답 프로토콜을 사용하도록 요구하지 않더라도 말이다.). 크리덴셜의 생성이나 보관에 대한 요구사항은 없다. 크리덴셜은 범용컴퓨터나 특수 목적 하드웨어에서 생성되거나 저장될 수도 있다.
예를 들어, 회사가 정부 기관에 전자적으로 기밀정보를 제출하는 거래는 LoA3의 인증 거래를 요구할 수도 있다. 부적절한 노출은 재정적 손실과 같은 중대한 위험을 야기할 수 있다. 다른 LoA3 거래 예제로는 어떤 개체가 특정 금융거래를 가능하게 하는 온라인 계정 접근이나 원격지의 제3의 계약자에 의한 잠재적으로 민감한 고객의 개인정보 접근을 포함한다.
4.4 보증 수준 4(LoA4)
LoA4에서는, 실제가 제기 또는 주장하는 신원에 대해 매우 높은 신뢰가 있다. 이 LoA는 잘못된 인증에 관련된 위험이 매우 높을 때 사용된다. LoA4는 이 표준에서 정의된 가장 높은 수준의 개체 인증 보증을 제공한다. LoA4는 LoA3과 유사하나, 사람인 개체에게 대해서는 직접적인 신원 검증을, 비밀 암호 키 혹은 개인 암호 키 보관을 위해서는 변경 방지된 하드웨어 장치의 사용을 요구하는 사항이 추가된다. 또한 모든 인증 프로토콜 내의 모든 PII와 기타 민감 데이터는 송신 중에나 저장될 때 암호로 보호되어야만 한다.
예를 들어, 인증 실패시 피해와 고통을 일으키는 높은 위험이 잠재된 서비스는 LoA4 수준의 보호를 요구할 수도 있다. 책임 있는 당사자는 완전한 보증, 즉 정확한 개체가 특정 중요 정보를 제공하고, 책임 있는 당사자는 그 정보의 검증이 잘못된 경우 형사책임을 질 수 있다는 보증이 필요하다. 마지막으로, 재정적 손실의 위험이 높은 거래의 승인은 LoA4 거래가 될 수도 있다.
LoA4에서 전자 인증서(예, ITU-T X.509, card-verifier(CV)인증서)는 노트북, 핸드폰, 프린터, 팩스기 등을 비롯한 네트워크에 연결되는 여러장치들과 같은 NPE를 인증하기 위해 사용될 수도 있다. 예를 들어, 스마트폰 등록 프로세스 중 전자 인증서를 스마트폰에 설치할 것을 요구할 수도 있다. 또한, 승인되지 않은 전력망으로의 접근을 막기 위해 스마트 미터 기술(smart meter technologies)을 적용하여 전자 인증서를 사용할 수도 있다.
4.5 적절한 보증 수준의 선택
적절한 LoA의 선택은 개체가 인증될 거래나 서비스의 위험 평가에 기초해야 한다. 영향 수준을 LoA에 맵핑함으로써 인증 거래의 당사자들은 자신들이 어떤 LoA를 필요로 하는지 결정할 수 있고 서비스를 구매할 수 있으며 그에 따라 보증된 신원을 신뢰할 수 있다. 표 2는 여러 LoA에서의 인증 실패에 의해 발생할 수 있는 결과와 영향을 나타낸다.
표 2 — 각 보증 수준에서 발생할 수 있는 영향
| 인증 실패로 발생할 수 있는 결과 | 인증 실패에 따라 각 보증 수준에서 발생 가능한 영향 |
|||
| 1 | 2 | 3 | 4 | |
| 지위 혹은 평판에 끼치는 불편, 고통 혹은 피해 | 낮음 | 중간 | 높음 | 매우 높음 |
| 재정적 손실 혹은 기관의 법적 책임 | 낮음 | 중간 | 높음 | 매우 높음 |
| 단체, 프로그램 혹은 공공 이익에 끼치는 피해 | 해당없음 | 낮음 | 중간 | 매우 높음 |
| 민감 정보의 인가되지 않은 유출 | 해당없음 | 중간 | 상당 | 매우 높음 |
| 개인의 안전 | 해당없음 | 해당없음 | 낮음~중간 | 높음~ 매우 높음 |
| 민사 혹은 형사 범죄 | 해당없음 | 낮음 | 높음 | 매우 높음 |
| 낮음-Minimum; 중간-Moderate; 높음-Substantial; 매우 높음-High; 해당없음-N/A | ||||
무엇이 낮음, 중간, 높음 그리고 매우 높은 위험을 구성하는지는 이 표준에서의 발생 가능한 각 결과를 사용하여 조직이 정의한 위험 기준에 따라 결정된다. 또한 복수의 영향 시나리오도 포함할 수 있다. 복수의 영향 시나리오에서는, 결과에 상응하는 LoA 중 가장 높은 것이 사용되어야 한다.
각 LoA는 강점과 통제의 엄격함, CSP가 서비스를 공급할 때 적용하는 EAAF의 각 절을 위한 프로세스의 엄격함에 의해 결정되어야만 한다. EAAF는 CSP를 위해 각 LoA에서의 운영 서비스 인증 기준에 대한 요구를 수립한다. 서비스 보증 기준은 9 절에 소개되어 있으나, 구체적인 요구사항은 본 기준의 범위에 포함되지 않는다.
해당되는 LoA를 결정하기 위해, 위험 평가의 결과를 사용할 때, 보안의 범위를 넘어서서 다른 비즈니스와 관련된 요소를 고려할 수 있다. 그런 비즈니스 요소는 다음과 같은 것일 수 있다.
a) 잔류 위험을 관리하기 위한 기관의 접근
b) 표 2에 나타난 영향면에서의 위험을 받아들이는 것에 대한 기관의 욕구
c) 서비스를 위한 비즈니스 목표(예, 만약 기관이 사기를 완화하는 프로세스를 가졌고, 사기의 위험을 받아들이기에 편하다면, 위험을 감수하기로 한 서비스는 비밀번호같은 크리덴셜을 사용하는 낮은 LoA가 더 도움이 될 수 있다.)
거래에 있어서 위험 평가는 기관의 전반적인 정보 보호 위험 평가의 부분으로서 이행될 수 있고(예, ISO/IEC 27001), 해당 거래의 보안을 위한 구체적인 요구에 집중해야 한다. 위험 평가는 EAA와 관련된 위험을 다뤄야만 한다. 위험 평가의 결과는 4 개의 LoA와 비교되어야만 한다. 위험 평가의 결과에 맞는 LoA가 채택되어야만 한다.
다수의 층위의 거래가 예상될 때, 서로 다른 LoA가 각각의 거래에 적용되는 것이 가능하다. 즉, 한 기관이 논의되고 있는 구체적인 거래에 따라 복수의 LoA를 받아들일 수 있다.
4.6 LoA 맵핑과 상호운용성
서로 다른 도메인은 LoA를 다르게 정의할 수 있다. 이 LoA는 꼭 이 프레임워크에 나타난 4 개의 LoA에 1 대 1로 맵핑되지 않을 것이다. 예를 들어, 한 도메인은 4 개의 수준의 모델을 쓸 수 있으나, 다른 도메인은 5 개 수준의 모델을 쓸 수 있다. 서로 다른 인증 모델을 위한 여러 기준은 반드시 별도로 정의되어야 하며 폭넓게 논의되어야 한다.
서로 다른 LoA 모델 사이에서 상호 운용성을 달성하기 위해서는, 각 도메인은 맵핑 스킴과 이 표준에서 정의된 LoA와 어떻게 연관되는지 다음과 같은 방식으로 설명해야만 한다.
a) 잘 정의된 LoA 카테고리를 포함하여, 잘 정의된 개체 인증 보증 방법론을 개발한다.
b) 이 방법론을 폭넓게 발표하여 연방 방식의 협약(federation-type agreement)에 가입하고 싶어하는 기관이 명확히 서로의 프로세스와 전문 용어를 이해할 수 있다.
LoA방법론은 다음의 사항들을 명세하고 정량화하는 위험 평가의 측면에서로서의 LoA를 고려해야만 하고, 명확히 정의해야만 한다.
a) 예상되는 위험
b) 위협이 현실이 될 때의 영향(즉, 낮음, 중간)
c) 각 LoA에서 통제되어야 할 위협의 식별
d) 각 LoA에서 통제를 시행할 때 사용하는, 권장되는 보안 기술과 프로세스. 예를 들어 하드웨어 장치(예, 스마트 카드)에서 처리되는(be carried on) 크리덴셜을 명세하거나 크리덴셜의 생성과 저장에 대한 요구 사항을 명시하는 것
e) 신원 검증과 관련된 크리덴셜 양자를 고려하여 만들어진 서로 다른 인증 요소의 조합이 동등한지 결정하기 위해 필요한 기준
서로 다른 LoA 모델로 구성한 맵핑/브리징(mapping/bridging) 문제를 다루기 위한 한 접근 방법으로서 이 문서에서 정의된 4-수준의 모델과, 이와 다른 n-수준의 모델을 사용할 수도 있다. 서로 다른 인증 보증 모델을 사용하는 신원 연맹은 이 방법을 통해 4-수준의 모델을 맵핑할 수 있다. 맵핑은 어떻게 매핑되지 않은 LoA가 처리될 것인지, 단순히 무시할 것인지 아니면 그 다음으로 낮은 수준에 효과적으로 맵핑을 할 것인지(왜냐하면, 사전에 특별히 결정되지 않았다면, 더 높은 LoA로 추정할 근거가 없을 수도 있기 때문이다.) 등을 정의해야만 한다.
4.7 4-수준의 LoA에 기초하여 교환된 인증 결과
인증 거래(예, CSP, RP)에 참가한 행위자는 거래나 활동을 완수하기 위해 정보를 교환할 필요가 있을 수 있다.
활동의 범위는 다음을 포함한다. 그러나 이에 제한되지는 않는다.
a) RP가 어느 LoA에서 개체가 인증되야 하는지에 대한 자신의 기대를 표현하도록 허용
b) 개체나 CSP가 대응으로써 실제 LoA를 지시하는 것을 허용
c) 개체나 CSP가 그 LoA와 관련된 요구사항을 충족할 능력이 있다는 게 인증되었음을 홍보하도록 허용
인증 거래에 참가한 행위자는 교환되는 정보의 프로토콜, 의미(semantics), 포맷과 구조에 동의해야만 한다. RP는 그가 정확히 요청한 것 외에 다른 인증 반응을 수용할 것인지 여부를 명시할 필요가 있을 수 있다.
디지털 인증서는 관련 크리덴셜의 보증에 대한 정보를 전달하는 데에 있어 확립된 방법인 반면, 메타데이터는 교환 당사자가 어떤 보증 요구 사항을 가지고 있는지 소통하기 위해 굉장히 많이 사용되고 있는 방법이다. 인터넷 주소(URL)의 형태로 된 '보안 주장 생성 언어(Security Assertion Markup Language, SAML) 인증 콘텍스트 클래스'와 같은 콘텍스트 클래스는, 당사자가 인증 요청과 주장 시에 인증 보증에 관련된 클래스들을 표현하는데 사용되는 잘 알려진 메카니즘이다. 예를 들어, 신원 제공자로부터의 전형적인 주장은 “이 사용자는 존 도(John Doe)이고, 그는 john.doe@example.com이라는 이메일 주소를 사용합니다. 그는 비밀번호 메카니즘을 사용하여 이 시스템에 인증하였습니다.”는 등의 정보를 전달할 수 있다.
이 프레임워크의 나머지 부분은 서비스를 위한 프로세스와 요구사항이 확립된 구조와 개체 인증과 관련 있는 위협과 영향을 설명한다. 그리고 충분한 크리덴셜 서비스를 달성하기 위해 적절한 LoA가 할당되었음을 보장하도록 서비스가 처리될 수 있는지에 대한 서비스 보증 기준의 필요성을 개괄하는 것으로 끝맺는다.
5 행위자
EAAF에 관련된 행위자에는 개체, CSP, RA, RP, 검증자, TTP 등이 포함된다. 이런 행위자들은 단일 조직이나 독립 조직에 속할 수 있다. 공유되거나 상호작용하는 요소, 시스템, 서비스와 같이, 여러 조직이 제공하는 다양한 관계와 능력이 존재할 수 있다.
5.1 개체
개체는 자신의 신원을 인증할 수 있다. 개체를 인증하는 능력은 여러 요소에 의해 좌우된다. 이 프레임워크의 문맥에 따르면, 개체를 인증하는 능력은 CSP가 개체를 등록하고 적절한 크리덴셜을 발행했음을, 그리고 인증 프로토콜이 명세되었음을 암시한다. 인증 도중, 개체는 스스로의 신원을 증명(attest)할 수 있다. 인증을 목적으로 개체를 대표하는 별도의 당사자가 존재하는 것 또한 가능하다.
5.2 크리덴셜 서비스 제공자
크리덴셜 서비스 제공자(CSP)는 크리덴셜 혹은 하드웨어, 소프트웨어 그리고 크리덴셜을 생산하는데 쓰일 수 있는 관련 데이터를 발행 및/혹은 관리한다. 비밀번호와 생체 측정 데이터는 CSP에 의해 발행되고 관리될 수 있는 크리덴셜의 예로 들 수 있다. 개인 키를 포함하는 스마트 카드는 CSP에 의해 발행되고 관리될 수 있는 하드웨어와 관련된 데이터(크리덴셜을 생산하는데 쓰일 수 있는)의 예로 들 수 있다. CSP는 또한 크리덴셜을 인증하기 위해 사용될 수 있는 데이터를 발행 및 관리할 수 있다. 만약 비밀번호가 크리덴셜로써 사용된다면, 이 데이터는 비밀번호의 일방향 기능값을 가질 수 있다. 만약 크리덴셜이 전자 서명된 정보에 기초한다면, CSP는 검증자가 사용할 수 있는 공개 키 인증서를 발행할 수 있다. 발행되고 제공된 크리덴셜과 CSP가 구현한 보호대책(safeguard)은, 특정 인증 거래를 할 동안 어떤 LoA에 도달할 것인지를 결정하는 주요 요소이다(8.3 항 참고).
이후 인증을 가능케 하기 위해선, 모든 개체에게 1 개 이상의 크리덴셜 혹은 크리덴셜을 생성하는 수단이 발행되어야만 한다. 크리덴셜 혹은 크리덴셜을 생성하는 수단은 보통 성공적인 등록 프로세스의 완료 후, 즉 개체가 등록이 완료된 시점에 발행된다.
5.3 등록 기관
등록 기관(RA)은 CSP에게 개체의 신원을 확립 및/또는 보증한다. RA는 개체 등록 단계에 관련된 프로세스를 수행하기 위해 CSP에게 신임을 받아야만 하며, 이후 CSP가 크리덴셜의 할당을 허용하는 방식으로 개체를 등록해야만 한다.
각 RA는 명시된 과정에 따라 신원 검증과 신원 정보 검증의 방식을 수행해야만 한다. 한 개체를 다른 개체로부터 구별하기 위해서, 개체는 보통 개체가 향후 적용 가능한 맥락에서도 인정받게 해주는, 하나 이상의 식별자를 배정한다.
5.4 신뢰 당사자
신뢰 당사자(RP)는 신원의 제기 또는 주장을 신뢰하는 행위자이다. 신뢰 당사자는 계정 관리, 접근 통제, 권한 결정 등 기타 다양한 목적을 위해 인증된 신원을 요구할 수 있다. 신뢰 당사자는 스스로 개체를 인증하는 데 필요한 작업을 수행하거나 제3자에게 이러한 작업을 맡길 수 있다.
5.5 검증자
검증자는 신원 정보를 확증하는 행위자이다. 검증자는 EAA의 다수의 단계에 참여할 수 있고 크리덴셜 검증 및/또는 신원 정보 검증을 수행할 수 있다.
5.6 신뢰할 수 있는 제3자
신뢰할 수 있는 제3자(TTP)는 기관이나 그의 대리인으로, 특정 활동(예, 보안 관련 활동)에 대해 다른 행위자의 신임을 받는다. 이 프레임워크에서, TTP는 인증을 목적으로서, 개체 및/또는 검증자의 신임을 받는다. 개체 인증을 목적으로 하는 TTP의 예는 인증 기관(CA)과 타임스탬프 발급기관이 포함된다.
6 개체 인증 보증 프레임워크 단계
이 절은 EAA 프로세스 단계와 프로세스에 대해 기술한다. 몇몇 EAA 모델은 이 모델의 구조와 다를 수 있으나, 이 모델과 일치하기 위해서는 기능 역량이 이 프레임워크에서 설정된 요구사항을 완전히 충족시켜야 한다. 이 프레임워크는 기술 중립적이다.
이 프레임워크를 채택하는 기관은 정책, 절차 및 필요한 지원 프로세스를 제공하고 이 프레임워크에서 제시된 요구사항을 충족하는 능력을 수립해야만 한다. 이것들은 일례로 어떤 기관에서 제공한 크리덴셜에 대한 LoA가 다양해지는 것처럼, 특정 기관이 선택한 역할에 따라 다양해질 것이다. 예를 들어, 기관은 다음의 대상이 될 수 있다.
a) 특정 LoA와 관련하여 조직을 대신하여 벌이는 특정 활동 혹은 조직의 대리에 대한 요구사항
b) 기관 운영 능력에 대한 외부 혹은 제3자의 평가에 대한 요구 사항
c) 이 프레임워크를 적용한 기관에 의해 제공되는 프로세스, 서비스, 능력의 신뢰성을 확립하기 위한 필요한 정책, 액션, 능력
6.1 등록 단계
등록 단계는 4 개의 프로세스로 구성된다(신청(application), 가입(initiation), 신원 검증(identity proofing, identity verification), 그리고 기록 보존/기록(record-keeping/recording)). 이 프로세스는 단일 기관에 의해 전적으로 수행될 수 있으며, 공유되거나 상호작용하는 요소, 시스템 서비스 등을 포함하여 여러 기관이 제공하는 다양한 관계와 능력으로 구성될 수 있다.
필수 프로세스는 적용 가능한 LoA에서 요구되는 엄격함에 따라 다르다. 개체가 LoA1 수준에서 등록하는 경우, 이런 프로세스는 최소화된다(예, 개인이 웹페이지의 “새로운 사용자(new user)”버튼을 누르고(may) 사용자 이름과 비밀번호를 생성할 수 있는 경우). 다른 경우에는 등록 프로세스가 광범위해질 수 있다. 예를 들어, LoA4에 등록하는 것은 광범위한 신원 검증과 동시에, 개체와 RA의 직접 대면(in-person meeting)을 요구한다.
6.1.1 신청과 가입
등록 단계는 다양한 방법으로 개시된다. 예로, 등록 단계는 특정 크리덴셜을 취득하려는 개체가 요청하여 시작될 수 있다(예, 웹사이트의 새로운 사용자가 사용자 이름과 비밀번호를 갖고자 할 때). 제3자가 개체를 대신하여 혹은 CSP 스스로가 등록 프로세스를 개시하는 것도 똑같이 가능하다(예, 정부가 발행하는 신원카드, 직원배지). 예를 들어, 높은 LoA에서의 신청은 제3자가 개체를 후원할 때만 수용될 수 있다.
어떤 경우에는, 등록 단계의 가입 프로세스는 신청서의 작성을 수반할 수 있다. 이 양식은 어떤 맥락 안에서 개체를 유일하게 식별할 수 있음을 보장하기 위해 충분한 정보를 기록해야 한다(예, 성명, 출생일, 출생지를 기록). 모바일 장치와 같은 NPE의 등록은 장치에 크리덴셜의 설치를 통한 초기화(initialization)를 요구할 수 있다. 이를 통해 장치는 유일하게 식별될 수 있고, 암호화된 배치 프로파일(encrypted configuration profile)을 통해 설정이 맞춰질 수 있다.
CSP는 어떤 조건 하에 등록이 제공되는지, 그 등록과 관련하여 어떤 서비스 하에서 사용되어야만 하는지 설정해야만 한다. 등록과 관련된 서비스의 조건은 신뢰 프레임워크를 통해 수립될 수 있다. 필요한 경우 등록 프로세스가 진행되기 전에 개체는 또는 그의 대리자가 면책조항(liability disclaimers) 또는 기타 법적 조항을 수용해야만 한다.
6.1.2 신원 증명과 신원 정보 검증
신원 증명은 개체를 식별하기 위해 명시되고 합의된 보증의 수준으로 충분한 정보를 포착하고 검증하는 프로세스이다. 신원 정보 검증은 신원 정보와 크리덴셜의 발행자, 데이터 원천 또는 기타 내외부 자원과 그의 진정성(authenticity), 타당성(validity), 정확성 및 개체에 대한 바인딩을 검사하는 프로세스이다. 상황에 따라, 권위 있는 출처에 의해 발행되고 승인된 다양한 신원 정보(예, 정부 신분증, 운전 면허증, 생체 정보, 기계 기반 입증(machine-based attestation), 출생 증명서)는 신원 증명 요구사항을 충족시킬 수 있다. 신원 검증 요구 사항을 충족시키기 위해 제출된 개체의 신원 정보는 LoA에 따라 다양하다.
신원 검증 단계에선 허위, 변조, 위조를 감지하기 위해 제출된 신원 문서의 물리적인 점검을 포함할 수 있다. 신원 검증은 또한 신원이 다른 맥락(예, 다른 RA에 의해 검증되었는지)에서 사용되는지 보장하기 위해 점검을 포함할 수 있다. 신원 검증 요구사항은 높은 LoA에서 보다 엄중해야만 한다. 또한, 개체가 원격에서 신원을 제기하거나 주장할 때(온라인 채널을 통해)의 신원 검증 프로세스는 직접 개체가 신원을 제기하거나 주장할 때(예, RA와의 대면)보다 엄중해야만 한다.
신원 검증 요구사항의 엄중함은 각 LoA 수준을 충족해야 한다는 목표에 기초한다. LoA1에서는 설정된 상황에서 신원이 유일한지 보장하는 것만을 목표로 한다. 신원은 다른 개체와 관계가 있어선 안된다. LoA2에서는 2개의 목표가 있다. 첫째로, 신원이 설정된 상황에서 유일해야만 한다. 두번째로, 신원이 적용되는 개체가 실재해야만(exist objectively) 한다. 즉, 신원이 허구이거나 사기를 목적으로, 의도적으로 날조되어선 안된다. 예를 들어 LoA2에서의 사람에 대한 신원검증은 출처를 분명히 하기 위해 출생 및 사망 등록을 확인하는 것을 포함할 수 있다(그러나 이는 출생신고서를 가진 개체가 그 출생신고서와 관계 있음을 증명하지는 않는다). 유사하게, LoA2 수준에서의 NPE에 대한 신원 검증은 제조사의 시리얼 넘버를 확인하는 것을 포함할 수 있다.
LoA3은 LoA1 및 LoA2의 목표를 포함하며, 외부 데이터베이스와 같이, 하나 이상의 권위있는 출처가 제공하는 신원 정보를 검증하는 목표 또한 포함한다. 신원 정보 검증은 신원이 사용 중에 있고, 개체와 관계가 있음을 보여준다. 그러나 신원 정보가 실제로 존재하고 적법한 소유자에게 소유되어 있는 것인지를 보장하지는 않는다. 사람에게는, LoA4는 LoA3의 목표에 더해 하나의 목표를 추가적으로 부과한다. LoA4는 사칭을 방지하기 위해 개체에게 면대면으로 만날 것을 요구한다.
높은 LoA에서의 신원 검증 프로세스는 낮은 LoA의 프로세스를 포함해야만 한다. 예를 들어, LoA3 신원 검증은 LoA1 및 LoA2의 신원 검증 통제가 만족되었음을 전제한다.
표 3 — 각 보증 수준에서의 신원 검증 목표 적용
| LoA | 설명 | 목표 | 통제 | 프로세스의 방법 |
| LoA1 –낮음 | 제기 또는 주장하는 신원에 신뢰가 적거나 없음 |
상황 내에서 신원이 유일하다. | 자체 제기 혹은 자체 주장 | 직접 혹은 원격 |
| LoA2 –중간 | 제기 또는 주장하는 신원에 약간의 신뢰가 있음 |
상황 내에서 신원이 유일하다. 신원이 적용되는 신원이 실재한다. |
권위있는 출처가 발급한 신원정보 사용을 통한 신원 검증 |
직접 혹은 원격 |
| LoA3 – 높음 | 제기 또는 주장하는 신원에 높은 신뢰가 있음 | 상황 내에서 신원이 유일하다. 신원이 적용되는 신원이 실재한다. 신원이 검증되었고, 신원이 다른 상황에서도 사용 중에 있다. |
권위있는 출처가 발급한 신원정보 사용을 통한 신원 검증 + 신원 정보 검증 |
직접 혹은 원격 |
| LoA4 – 매우 높음 | 제기 또는 주장하는 신원에 매우 높은 신뢰가 있음 |
상황 내에서 신원이 유일하다. 신원이 적용되는 신원이 실재한다. 신원이 검증되었고, 신원이 다른 상황에서도 사용 중에 있다. |
권위있는 출처가 발급한 신원정보 사용을 통한 신원 검증 + 신원 정보 검증 + 면대면 개체 검증 |
직접만 가능 |
등록 프로세스 중 발생가능한 위협에 대해 보호하기 위해 요구되는 LoA 통제는 8.1.2 항에 기재된 통제의 사용에 따라 결정되어야만 한다,
모든 EAAF의 이행은 개체 및/또는 RA가 사용할 수 있는 신원 정보와 출처(의 부분집합)에 의존한다.
이 크리덴셜, 신원 정보 그리고 출처의 신뢰도와 정확성이 등록 단계에서 제공되는 실제 보증을 결정짓는다. 결과적으로 신원 검증 및 신원 정보 검증을 목적으로 어떤 크리덴셜, 신원 정보 및/또는 출처를 신뢰할 것인지 결정할 때, EAAF의 이행자는 서로 다른 출처와 발행자에 의해 사용되는 신원 (관리) 기반 시설이 제공한 보증을 주의 깊게 고려해야만 한다. EAAF의 모든 이행은 등록 단계에 제공되어 신뢰받는 신원 정보, 출처 및/또는 발행자의 개요를 제공하는 문서의 발행(예, 8.1.2.1 항에 쓰인 신원 검증 정첵)을 수반해야만 한다.
6.1.3 기록 보존/기록
이것은 개체 등록의 마지막 프로세스이다. 이것은 등록 기록이 생성되는 등록 단계의 기록 보존 프로세스이다. 이 기록은 수집된(보유할 수 있는) 정보와 문서, 신원 정보 검증 프로세스와 관련된 정보, 각 단계들의 결과, 그 외 관련 데이터를 포함해야만 한다. 그 뒤 결정이 제출되고, 수락, 거절 혹은 재검토 혹은 그 외 후속조치를 위한 회부가 기록된다.
6.1.4 등록
등록은 개체가 서비스나 자원의 사용을 요청하는 프로세스이다. 등록 프로세스가 일반적으로 등록(enrolement) 프로세스의 부분으로 여겨지고, 등록 단계의 마지막 단계에서 수행되나, 등록 프로세스는 또한 차후에 수행될 수 있다. 오로지 한번으로 충분할 수 있는 다른 프로세스의 등록과 달리, 등록은 개체가 각 서비스나 자원에 처음으로 접근을 요구할 때 필요할 수 있다.
6.2 크리덴셜 관리 단계
크리덴셜 관리 단계는 크리덴셜 라이프 사이클 관리, 크리덴셜 발행 수단과 관련 있는, 사용자가 활동이나 상황에 참여할 수 있게 해주는 모든 프로세스를 포함한다. 크리덴셜 관리 단계는 다음의 단계들의 일부분 또는 모두를 수반할 수 있다(크리덴셜의 생성, 크리덴셜 발행 또는 크리덴셜을 생성하는 수단, 크리덴셜의 활성화 또는 크리덴셜을 생성하는 수단, 크리덴셜의 저장, 크리덴셜의 철회 및/또는 폐지 또는 그를 생성하는 수단, 크리덴셜의 갱신 및/또는 교체 또는 그를 생성하는 수단, 그리고 기록 보존). 몇몇의 프로세스는 크리덴셜이 하드웨어 장치에 담겨있는지, 아닌지에 좌우된다.
6.2.1 크리덴셜 생성
크리덴셜 생성 프로세스는 처음으로 크리덴셜을 생성하거나(create), 크리덴셜을 생성하는(produce) 수단을 만드는 데 필요한 모든 프로세스를 아우른다. 이 프로세스는 전처리(pre-processing), 초기화, 바인딩(binding)을 포함할 수 있다.
6.2.1.1 크리덴셜 전처리
어떤 크리덴셜, 또는 크리덴셜을 생성하는 수단은 발행 전, 크리덴셜이 개체의 신원에 맞도록 개인화(personalization)를 하는 등의 전처리를 해야 한다. 개인화는 크리덴셜에 따라 서로 다른 많은 형태를 취할 수 있다. 예를 들어, 크리덴셜을 담은 스마트 카드의 개인화는 개체가 받을 카드에 개체의 이름을 프린트하거나(카드 겉면에) 쓰는 것을(카드 칩에) 수반할 수 있다. 비밀번호와 같이 개인화가 필요하지 않은 크리덴셜도 있다.
6.2.1.2 크리덴셜 초기화
크리덴셜 초기화는 크리덴셜을 생성하는 수단이 지원할 것이라고 기대하는 기능을 향후 지원하게 될 것이라고 보장하기 위한 모든 단계를 아우른다. 예를 들어, 스마트 카드 칩은 향후에 전자 서명의 생성을 지원하는 암호 키 페어를 산출하도록 요구받을 수 있다. 비슷하게, 스마트 카드는 활성화 프로세스 중에 PIN을 필요로 하는 “잠금“ 상태로 발급될 수 있다.
6.2.1.3 크리덴셜 바인딩
바인딩은 크리덴셜 또는 크리덴셜을 생성하는 수단과 그것들을 소유할 개체와의 연계를 이뤄내는 프로세스이다. 어떻게 바인딩이 완수되는지와 바인딩 연계에 있어서의 신뢰는 LoA에 따라 다양해진다. 예를 들어 온라인 시나리오에서, 개체가 지속적으로 사용해온 가명의 신원자와 개체의 고객 기록을 바인딩할 때, 바인딩 프로세스를 통해 처음으로 보안 채널(secured channel) 안의 세션온리 암호화 쿠키(session-only encrypted cookie)에서 “활성화 코드(activation code)”가 수행될 수 있다. 그 대신에, 한번 개체와 지속적으로 사용된 신원을 바인딩하는 단계가 완료되면, 지속적으로 사용된 신원과 고객 기록을 바인딩하기 위해, 활성화 코드는 프로세스의 마지막 단계에서 요구될 수 있다.
6.2.2 크리덴셜 발행
크리덴셜 발행은 제공 혹은 그 반대로 개체와 특정 크리덴셜, 또는 크리덴셜을 생성하는 수단과의 연계하는 프로세스이다. 이 프로세스의 복잡성은 요구된 LoA에 따라 다양해진다. 높은 LoA는 크리덴셜을 담은 하드웨어 장치(예, 스마트 카드)의 안전한 전달을 요구할 것이고, 장치를 직접 배달하도록 요구할 수 있다. 낮은 LoA의 경우에는, 발행 프로세스는 비밀번호 또는 PIN을 물리적인 개체 또는 이메일 주소로 보내는 것만큼 쉬울 수 있다.
장치와 같은 NPE를 위한 높은 LoA에서의 발행 프로세스는 보통 CSP에게 각 디지털 인증서에 할당될 유일한 장치 신원 번호의 목록을 제공하는 것을 통해 장치 제조사가 산적화물로 디지털 인증서를 주문하는 것으로 시작된다. CSP는 인증서와 개인 키를 암호화된 방식으로 제조사에 제공하는 것으로 답한다. 제조 단계 중, 제조사는 디지털 인증서를 각 장치에 끼워 넣어 유일한 장치 식별자를 만들 수 있다.
6.2.3 크리덴셜 활성화
크리덴셜 활성화는 크리덴셜, 또는 크리덴셜을 생성하는 수단을 사용할 수 있도록 준비하는 프로세스이다. 활성화 프로세스는 크리덴셜에 따라 다양한 조치를 수반할 수 있다. 예를 들어, 크리덴셜, 또는 크리덴셜을 생성하는 수단은 초기화된 이후 개체가 발행하는 순간 이전까지 중간 남용을 막기위해 “잠금” 상태로 있을 수 있다. 이런 경우에는, 활성화가 크리덴셜의 “잠금 해제(unlocking)”를(예, 비밀번호의 사용) 수반할 수 있다. 크리덴셜 또는 크리덴셜을 생성하는 수단은 또한 유효성이 일시적으로 정지하는 지연(suspension) 후에 재활성화될 수 있다.
6.2.4 크리덴셜 저장
크리덴셜 저장은 크리덴셜 또는 크리덴셜을 생성하는 수단이 비인가된 유출, 사용, 수정, 또는 파괴로부터 보호되는 방식으로 안전하게 저장되는 프로세스이다. 크리덴셜 저장은 크리덴셜과 관련된 개체와 활동이 크리덴셜의 비인가된 사용으로부터 보호받아야함을 요구하는 것을 수반한다.
크리덴셜 저장은 크리덴셜이 합법적인지를 확인할 때 사용된 정보에 대해, 그 정보가 크리덴셜의 일부가 아니라면, 보호할 필요는 없다. 인증에 요구된 해쉬된 비밀번호의 표와 같은 정보에 대한 보호는 높은 LoA에서 요구된다.
6.2.5 크리덴셜 보류, 폐지 및/또는 파괴
폐지는 크리덴셜의 유효성이 영구적으로 종결되는 프로세스이다. 보류는 크리덴셜의 유효성이 일시적으로 정지되는 것과 관련된 프로세스이다. 많은 상황에서 폐지하는 것이 적절할 수 있다. 다음과 같은 상황에서는 폐지를 해야만 한다.
a) 크리덴셜 또는 크리덴셜을 생성하는 수단이 분실, 절도, 또는 다른 침해가 있었던 것으로 발표되었을 때
b) 크리덴셜이 만료되었을 때
c) 크리덴셜의 근거가 더 이상 존재하지 않을 때(예, 고용인이 사용자를 떠났을 때)
d) 크리덴셜이 비인가된 목적을 위해 사용되었을 때
e) 다른 크리덴셜이 논의되고 있는 크리덴셜을 대체하기 위해 발행되었을 때
폐지를 요구하는 사건의 알림과 폐지 프로세스가 완료되는 사이의 시간 간격(time frame)은 운영정책에 따라 결정된다. 높은 LoA에서는, 폐지하도록 시한은 일반적으로 짧다. 스마트카드에 설치된 것과 같은 어떤 크리덴셜은 물리적으로 파손되어 폐지될 수 있다. 그러나, 크리덴셜과 관련된 정보는 항상 파기될 수는 없다.
6.2.6 크리덴셜 갱신 및/또는 교체
갱신은 존재하는 크리덴셜의 주기를 연장하는 프로세스이다. 교체는 이전에 발급되어 폐지된 크리덴셜을 대체하기 위해, 개체가 새로운 크리덴셜 또는 크리덴셜을 생성하는 수단을 발급받는 프로세스이다. 교체 크리덴셜의 예로 CSP가 개체의 이메일 주소로 임시 비밀번호를 보내 그를 기입한 뒤, 개체가 새로운 비밀번호를 만들 수 있게 하는 것을 들 수 있다. 다른 예는 PIN 잠금 해제 코드이며, PIN처럼 사용되어야 한다. 크리덴셜 갱신 및 교체를 하기 위한 프로세스의 엄격함은 LoA에 따라 다양하다.
6.2.7 기록관리
적절한 기록은 크리덴셜의 생명주기(lifecycle)동안 보존되어야만 한다. 최소한 기록은 다음과 같은 정보를 기록하여 보존해야만 한다.
a) 크리덴셜이 생성되었다는 사실
b) 크리덴셜의 식별자(해당되는)
c) 크리덴셜이 발급된 개체(해당되는)
d) 크리덴셜의 상태(해당되는)
기록은 크리덴셜 관리 단계에 수반되는 모든(해당되는) 프로세스를 보존해야한 한다. 크리덴셜이 사람인 개체에 발급되었을 때, 기록 관리는 PII의 프로세싱을 수반할 가능성이 높다(부속서 B 참조)
6.3 개체 인증 단계
개체 인증 단계에서는, 개체는 RP에게 신원을 증명하기 위해 그의 크리덴셜을 사용한다. 인증 프로세스는 오로지 제기 또는 주장한 신원의 신뢰를 쌓기 위한 것으로 여겨지고, 신뢰당사가가 제기 혹은 주장에 근거를 둘지 선택할 수 있는 행위와 전혀 무관하다.
6.3.1 인증
인증 단계에는 신원의 신뢰를 쌓기 위한 크리덴셜의 소유 및/또는 통제를 입증하기 위해 프로토콜의 사용이 포함된다. 인증 프로토콜 요구사항은 적용가능한 LoA에 따라 다양하다. 예를 들어, 낮은 LoA에서는 인증에 비밀번호의 사용을 수반할 수 있다. 높은 LoA에서는 인증에 암호 방식의 도전-응답 인증 프로토콜의 사용을 수반할 수 있다. 높은 LoA에서는 다중인증이 요구된다. 모든 인증요소가 같은 강도의 효과를 제공하지는 않고, 복수의 요소가 보증을 높이기 위해 사용된다(8 절 참조)
6.3.2 기록관리
인증단계에서의 사건에 대한 모니터링과 기록관리는 서비스 제공, 준수, 의무 및/또는 법률 요건 등 다양한 목적을 위해 필요할 수 있다.
사람 개체를 고려할 때, 기록에 포함된 정보는 민감정보를 포함할 수 있다. 이 기록들은 보호될 필요성과 PII의 최소화를 어느 정도 고려하여 관리되어야만 한다.
7 관리 및 운영사항
EAA는 기술적 요소에서만 기인하지 않고(come from), 규제, 계약상의 협약 및 서비스 제공이 어떻게 관리되고 운영될 것인지에 대한 고려사항 등에 의해서도 기인한다. 능숙한 관리 및 운영 없이 수행되는 기술적으로 엄격한 솔루션은 EAA 제공에 있어 보안이 제대로 제공되지 않을 수 있다. 이 절은 유익하면서 EAA에 영향을 끼칠 수 있는 운영 및 관리 고려사항을 서술한다. 이 절은 각 LoA에서 구체적인 기준을 제공하지는 않는다. 구체적인 기준 및 관리 및 운영 고려사항을 위한 적합성 평가(conformance assessment)는 이 기준에 포함되지 않으나, 신뢰 프레임워크 내에서 제공되어야 한다.
7.1 서비스 수립
서비스 수립은 서비스 제공자의 합법적 상태(legal status)이자 기능적인 서비스 제공의 상태를 호칭한다. 예를 들어, 신원 관리 및 인증 서비스의 제공자가 등록된 법적 개체임을 아는 것을 통해 CSP가 운영하는 관할 구역내에서 CSP가 진실된 기업이라는 신뢰를 줄 수 있다. 이는 서비스 요소가 서로 다른 법적 개체(예, 다른 기능으로서 등록)에 의해 운영될 때 더욱 중요해진다.
기본적인 요구사항은 모든 LoA에서 같으나, 높은 LoA는 완벽하고 신뢰할만한 서비스를 제공하는 것에 대해 더 신경써야 한다. 예를 들어 LoA3 이상의 수준에서는, 회사 가맹 관계에 대한 지식, 운영에 있어 합의된 독립성 수준에 대한 이해에 기반하여, 서비스 제공에 더 큰 보증을 해야 한다.
7.2 법 및 계약 준수
모든 EAAF 행위자는 모든 서비스의 운영과 전달과 관련하여 필요한 법적 요구사항 이해하고 준수해야 한다. 이는 찾을 수 있는 정보 종류에 국한되지 않고, 어떻게 신원 검증이 수행되는지, 어떤 정보를 보유할 것인지를 함축한다. PII를 다루는 것은 특정한 법적 업무이다(부속서 B 참조). 계약은 행위자가 운영하는 관할권 내에서 이루어져야 한다. LoA2이상의 수준에서는, 특정한 정책과 계약상의 요구사항이 확인되어야 한다.
7.3 재무적 조건
개체와 신뢰 당사자 양자 모두 서비스의 장기적효용성을 기대하고 고려하고 있을 때 재무적 안정성 측면에서 서비스 활동의 지속성을 보장할 수 있는지, 보유하고 있는 위험 노출(liability exposure)의 정도를 감당할 수 있는지를 충분히 납득시켜야 한다 LoA1 서비스와 릴라이언스(reliance)에서는 이러한 재무적 조건이 고려사항이 아닐 가능성이 높으나, 중요한 거래를 지원하는 LoA2 수준 이상의 서비스는 이런 필요를 다루어야 한다.
7.4 정보보안 관리 및 감사
LoA2 이상의 수준에서는 EAAF행위자는 문서화된 정보 보안 관리 관행, 정책, 위험 관리로의 접근 및 다른 알려진 통제들을 운영하고 있어야 하며, 이는 효과적인 실무 관행이 적용되고 있음을 보증하기 위해서이다. LoA3 이상의 수준에서는, 공식적인 정보보안 관리 체계(예, ISO/IEC 27000)가 사용되어야 한다.
법, 계약 및 기술적 준수에 대한 협약에 따라, 행위자는 당사자가 정한 협약을 준수하도록 보장해야하고, 그러지 않을 시 시정하기 위한 방안을 제공할 수 있다. LoA2 이상의 수준에서는, 이 보증이 내외부적 보안 감사에 의해 지원되어야 하고, 감사를 포함하여 중대한 사건에 대한 기록을 안전하게 보존하여야 한다. 감사는 당사자의 관행이 서로 동의한 바를 따르고 있는지를 확인하는데 사용될 수 있다. 분쟁처리 서비스는 의견 충돌이 있을 때 사용될 수 있다.
7.5 외부 서비스 구성요소
어떤 기관이 그 서비스의 일부를 제3자에 의탁한다면, 이 제3자에게 행동을 지시하는 방법과 감독하는 방법은 모든 서비스 보증에 관련된다. 협의된 배치(arrangement)의 종류와 정도는 할당된 LoA에 따라 적용된 정보보안 관리체계 수준에 비례해야 한다. LoA1에서는 이들이 보증에 제공하는 영향이 최소화되지만 LoA2 이상에서는 이러한 수단들이 보증에 전반적으로 영향을 미친다.
7.6 운영 인프라
대규모의 신뢰 네트워크를 구성하기 위해서는, 신뢰 프레임워크가 사용될 수 있다. 신뢰 프레임워크에서 행위자는 다른 행위자 간의 정보흐름(information flow)를 지원한다. 협약에 따라, 부가적인 행위자는 모든 행위자가 협약을 잘 준수하는지 보장할 필요가 있을 수 있고, 그렇지 않을 시 시정하기 위한 방안을 제공할 수 있다.
7.7 운영 능력 측정
정책 입안자는 신뢰 프레임워크를 위한 기술 및 계약 상의 요구사항을 준비한다. 예를 들어, 기술적 요구사항에 제품 버전 수준(product version levels), 시스템 구성(system configuration), 세팅 및 프로토콜 등을 포함할 수 있는 반면, 계약 상의 요구사항을 공정 정보 규정(fair information practices)에 맞게 설계할 수 있다. 정책 입안자는 이런 요구사항을 수립하며, 예상 신뢰 프레임워크 개체를 측정할 수 있는 기준을 그에 포함해야 한다. 그들 스스로 기준을 발전시키는 것보다, 정책 입안자는 이 기준과 같이, 이미 전문가들이 만들어 논, 인정된 기준을 취하고 싶을 수 있다. 더 많은 정책 입안자들이 서로 다른 신뢰 프레임워크에 인정된 기준을 적용한다면, 개체가 일관되게 기준을 이해하고 적용하기 쉬울 것이다. 게다가, 저명한 기준의 집합은 다양한 LoA 수준에서의 요구사항이나 능력에 있어 서로 다른 정도 또는 종류의 엄격함을 표시하는 약칭(shorthand)으로 사용될 수 있다.
8 위협 및 통제
이 절은 EAAF 각 단계에서의 위협을 설명하였으며 각 LoA 에서 요구되는 통제를 제공한다.
8.1 등록 단계에 대한 위협 및 통제
8.1.1 등록 단계에서의 위협
표 4는 등록 단계에서의 위협을 규정하고 설명한다.
표 4 — 등록 단계에서의 위협
| 위협 | 예시 |
| 사칭 | 사칭의 예시로는 개체가 불법적으로 다른 개체의 신원 정보를 사용하거나, 위조된 매체 접근 제어(MAC) 주소를 사용하는 네트워크의 장치를 등록하는 것을 들 수 있다. |
8.1.2 등록 단계에서의 위협으로부터 보호하기 위해 요구되는 LoA 통제
표 5는 등록 단계에서 LoA에 따라 요구되는 통제를 규정한다.
표 5 — 등록 단계에서의 각 LoA에 대한 통제
| 위협 | 통제 | 요구되는 통제 | |||
| LoA1 | LoA2 | LoA3 | LoA4 | ||
| 사칭 | 신원 검증 : 정책 고수 | #1 | #1 | #1 | #1 |
| 신원 검증 : 대면 | #2 | ||||
| 신원 검증 : 권위있는 정보 | #3 | #4 | #5 | #6 | |
비고 위의 표에서, 식별자 #1 - #6은 각 LoA에서 보호를 제공하기 위해 구체적으로 요구되는 통제와 상응한다. 각각의 통제는 8.1.2.1 항에 구체적으로 나타나 있다. 표 안의 항목에 있는 대각선은 각각의 통제가 해당 LoA에서 적용 가능하지 않다는 것을 나타낸다.
8.1.2.1 등록 단계의 위협에 대한 통제
다음 등록 단계의 위협에 대한 통제는 표 5에 실린 #1 - #6과 상응한다.
신원 검증 : 정책 고수
#1. 신원 검증 정책을 공표하고, 모든 신원 검증을 그에 맞게 수행한다.
신원 검증 : 대면
#2. 대면 신원 검증은 사람에게 사용되어야만 한다.
신원 검증 : 권위있는 정보
#3. 신원 정보는 스스로 제기 혹은 주장될 수 있다.
#4. 다음 통제가 적용된다.
• #3으로부터의 모든 통제
추가적으로:
• 개체는 적어도 한 정책에 따라 권위있는 출처의 신원 정보를 제공해야만 한다.
a) 사람에 대하여
i) 직접 대면
• 개체가 적어도 한 정책에 따라 권위있는 출처의 신원 문서를 반드시 소지하고 있어야 한다. 문서에는 소유자와 개체의 모습이 일치하는 사진을 포함해야 한다.
• 제출된 신원 문서는 반드시 진품이여야 하며, 적절하게 발급되었고 적용할 시 유효해야 한다.
ii) 대면이 아닌 경우:
• 개체는 본인이 정책을 준수하는 개인 신원 정보를 소유하고 있다는 것에 대한 증거를 제공해야만 한다(허용되는 신원 정보의 예로 운전면허증 또는 여권이 포함될 수 있다).
• 제공된 증거의 존재와 유효기간은 정책 요구사항에 따라 확인하여야만 한다.
b) NPE에 대하여:
• 실명(common name), 설명서, 시리얼 번호, MAC주소, 소유자, 위치, 제조사 등, 신원 정보에 대해 권위있는 출처의 기록 정보.
#5. 다음 통제가 적용된다.
• #4으로부터의 모든 통제
추가적으로:
a) 사람에 대하여
i) 직접 대면:
• 개체에 연락하여 신원 문서에 열거된 연락처의 정확도를 검증
• 적어도 하나의 신원 문서(예, 출생, 결혼, 또는 이주를 입증하는 문서)를 관련 권위있는 출처의 기록으로부터 검증
• 적용가능한 권위있는 정보 출처의 개인정보와 (가능하다면) 유일한 신원을 보장하기에 충분한, 다른 상황에서 사용된 개인 정보를 확증
• 개체가 이전에 제공한 또는 개체가 제공했다고 할 수 있는 정보를 검증
ii) 대면이 아닌 경우:
• 개체가 제기/주장하는, 권위있는 출처의 LoA3(또는 그 이상) 수준의 크리덴셜이 제 3의 신뢰당사자에 의해 확인됨을 보장; 및/또는
• 개체가 이전에 제공한 또는 개체가 제공했다고 할 수 있는 정보를 검증
b) NPE에 대하여:
— 신뢰받는 하드웨어(예, TPM)는 LoA3에서 사용되어야만 한다.
— 이미 사용되고 있던 NPE는 RA가 사용하는, 사람이 발급한 LoA3의 크리덴셜을 설치한 장치에 물리적으로 등록되어야만 한다. 신뢰할 수 있는 하드웨어가 사용될 때 신뢰할 수 있는 하드웨어가 사용될 때 NPE가 활성화되어야 한다.
— 아직 확보되지 않은 NPE는 지시한 개체가 NPE를 지시할 권한이 있음을 확인하기 위해 LoA3의 사람 인증 또는 전자 서명을 사용하여 지시 받아야만 한다. 제조사의 RA는 NPE를 등록해야만 하고, 모든 신뢰할 수 있는 하드웨어 또한 활성화하여야하고, 발행을 통제해야만 하고, NPE를 개인화해야만 한다. 신뢰받는 하드웨어는 네트워크와 연결될 때 초기화될 것이다.
— 컴퓨터가 아닌 NPE에 대해, 장치, 소유자, 네트워크, 또는 통신 사업자 및 RA 간의 바인딩은 신뢰할 수 있는 하드웨어 컴퓨터에 대한 것과 유사한 방식으로 암호화하여 보호해야만 한다.
— 소프트웨어를 사용할 때, 코드는 발행되기 전에 사람이 발급한 크리덴셜, LoA3과 함께 전자 서명되어야만 하며, 사용되기 전에 RA가 승인의 증거로서 추가 서명해야만 한다.
#6. 다음 통제가 적용된다.
• #5으로부터의 모든 통제
추가적으로:
a) 사람에 대하여
— 개체는 적어도 하나 이상의 정책을 준수하는 권위있는 출처의 신원 정보를 추가적으로 제공해야만 한다.
b) NPE에 대하여
— 컴퓨터, 스마트폰, 혹은 비슷한 프로세서에 연결되는 추가적인 장치는 발행시 기록되어야만 하며, 발행 시 모체 장치(예, 장치 사용을 가능케 하는 신뢰받는 하드웨어, 생체 측정 장치, 스마트 카드, GPS 기반 위치 인증 프로그램(GPS geo-authenticator))와 암호화되어 바인딩되어야만 한다.
— 장치 간의 바인딩 배열에 있어 모든 변화는 RA를 통해 관리되어야만 한다. 가능하다면, 네트워크 관리 능력은 장치 간 관계의 모든 변화 및 교정된 모든 행위를 RA 또는 네트워크 관리에 경고해야 한다.
- 작동 중 장치 간의 관계에 대한 모든 변경을 예방하기 위한 능력이 운영되어야만 한다.
- LoA4 소프트웨어 코드는 LoA4, 사람이 발급한 크리덴셜과 전자 서명이 되야만 하며, 사용되기 전에 RA가 승인의 증거로서 추가 서명해야만 한다.
8.2 크리덴셜 관리 단계에 대한 위협 및 통제
8.2.1 크리덴셜 관리에서의 위협
아래 표 6은 크리덴셜 관리 단계에서의 위협을 나열하였다.
표 6 — 크리덴셜 관리 위협
| 위협 | 예시 |
| 크리덴셜 생성: 부당변경 | 등록 프로세스에서 크리덴셜 생성 프로세스로 넘어가는 중에 공격자가 정보를 변경한다. |
| 크리덴셜 생성: 인가되지 않은 생성 | 공격자가 CSP가 가상의 개체를 기반으로 크리덴셜을 생성한다. |
| 크리덴셜 발행: 유출 | 크리덴셜 수립 중 CSP가 개체를 위해 생성한 크리덴셜이 개체에게 전송될 때, 공격자가 크리덴셜 복제한다. |
| 크리덴셜 활성화: 인가되지 않은 소유 | 공격자가 본인의 것이 아닌 크리덴셜을 소유하고, 정당한 개체임을 가장하여 CSP가 크리덴셜을 활성화하게 한다. |
표 6 — 크리덴셜 관리 위협(계속)
| 크리덴셜 활성화: 비가동률 | 1. 크리덴셜 혹은 크리덴셜을 생산할 수 있는 수단과 관련있는 개체가 원래 있던 위치에 있지 않고 그 신원을 CSP에게 적절히 인증할 수 없다. 2. 크리덴셜 혹은 크리덴셜을 생산할 수 있는 수단의 전달이 늦어져, 정해진 기간 내에 활성화가 불가능하다. |
| 크리덴셜 저장: 유출 | 시스템 파일에 저장된 크리덴셜이 유출된다. 예를 들어, 사용자 이름과 비밀번호에 대해 저장된 기록에 공격자가 접근한다. |
| 크리덴셜 저장: 부당변경 | 사용자 이름을 크리덴셜에 맵핑한 파일이 침해되어 맵핑이 수정되고, 본래의 크리덴셜이 공격자가 접근할 수 있는 크리덴셜로 대체된다. |
| 크리덴셜 저장: 복제 | 공격자가 저장된 정보를 사용하여 인가되지 않은 개체가 사용할 수 있는 복제 크리덴셜을 생성한다.(예, 크리덴셜을 생성할 수 있는 스마트 카드를 복사한다.) |
| 크리덴셜 저장: 개체에 의한 유출 | 개체가 다른 사람이 접근할 수 있는 장소에 사용자 이름과 비밀번호의 기록해 둔다. |
| 크리덴셜 폐지: 지연된 폐지 | 폐지 정보가 적시에 제공되지 않아, 검증자가 최신 폐지 정보를 업데이트하기 전에 개체가 폐지된 크리덴셜을 사용하여 인증할 수 있다. |
| 크리덴셜 폐지: 폐기처분 후 사용 | 피고용자가 회사를 떠날 때, 사용자 계정을 삭제하지 않아 인가되지 않은 개인이 구계정을 남용한다. -하드웨어 장치에 저장된 크리덴셜을 암호화된 키가 폐지된 이후에도 사용한다. |
| 크리덴셜 갱신: 유출 | 개체를 위해 CSP가 갱신한 크리덴셜을 공격자가 복사하고 전송한다. |
| 크리덴셜 갱신: 부당변경 | 만료된 크리덴셜을 대체하기 위해, 개체가 새로 생성한 크리덴셜을 CSP에 제출할 때, 공격자가 수정한다. |
| 크리덴셜 갱신: 인가되지 않은 갱신 | 공격자가 취약한 크리덴셜 갱신 프로토콜로부터 현재의 개체를 위해 크리덴셜 유효기간을 늘리는 이득을 취한다. 공격자가 현재 개체에게 CSP가 새로운 크리덴셜을 발급하도록 속이고, 현재 개체의 신원을 공격자가 제공한, 새로운 크리덴셜과 연동하는 것이다. NPE 개체에 대해서는 시스템 요소(예, RAM)가 사용되고 나서 새로운 것으로 재표기(재발행)하는 예가 있을 수 있다. |
| 크리덴셜 기록관리: 부인 | 사용해 온 크리덴셜을 거짓으로 부정하기 위해 개체가 타당한 크리덴셜을 사기 혹은 사실이 아닌 정보를 함유하고 있다고 제기 또는 주장한다. |
8.2.2 크리덴셜 관리 단계에서의 위협으로부터 보호하기 위해 요구되는 LoA 통제
표 7은 LoA에 따라 크리덴셜 관리 위협으로부터 필요한 통제를 규정하였다.
표 7 — 크리덴셜 관리 단계에서의 각 LoA에 대한 통제
| 위협 | 통제 | 요구되는 통제 | |||
| LoA1 | LoA2 | LoA3 | LoA4 | ||
| 크리덴셜 생성: 부당변경 | 적절한 크리덴셜 생성 | #1 | #1 | #2 | #2 |
| 하드웨어만 가능 | #3 | ||||
| 잠금 상태(State locked) | #4 | ||||
| 크리덴셜 생성: 인가되지 않은 생성 |
인벤토리 추적(Tracked inventory) | #5 | #5 | #5 | #5 |
| 크리덴셜 발행: 유출 | 적절한 크리덴셜 발행 | #6 | #7 | #7 | #8 |
| 크리덴셜 활성화: 인가되지 않은 소유 비가동률 |
개체에 의한 활성화 | #9 | #9 | #10 | #11 |
| 크리덴셜 저장: 유출 부당변경 복제 개체에 의한 유출 |
크리덴셜 보안 저장 | #12 | #13 | #14 | #15 |
| 크리덴셜 폐지: 지연된 폐지 폐기처분 후 사용 |
크리덴셜 보안 폐지 및 파기 | #16 | #16 | #16 | #16 |
| 크리덴셜 갱신: 유출 부당변경 인가되지 않은 갱신 |
크리덴셜 보안 갱신 | #17 | #17 | #18 | #19 |
| 크리덴셜 기록관리: 부인 | 기록 유지 | #20 | #20 | #21 | #21 |
비고 위의 표에서, 식별자 #1-#21은 각 LoA에서 보호하기 위해 요구되는 구체적인 통제와 상응한다. 각 통제는 8.2.2.1 항에 구체적으로 설명되어 있다. 표 항목에 있는 대각선은 각 통제가 해당되는 LoA에 적용이 가능하지 않다 것을 나타낸다.
8.2.2.1 크리덴셜 관리 단계의 위협에 대한 통제
다음 크리덴셜 관리 단계의 위협에 대한 통제는 표 7에 나열된 번호 #1-#21과 부합한다.
적절한 크리덴셜 생성
#1. 다음 통제를 적용한다.
• 크리덴셜 생성에는 공식화되고 문서화된 프로세스를 사용하여야만 한다.
• 크리덴셜을 개체와 바인딩하는 것을 끝내기에 앞서, CSP는 크리덴셜이 적절한 개체와 연동되었고, 연동된 상태임을 나타내는 적절한 보증을 갖춰야 한다.
#2. 다음 통제를 적용한다.
• #1의 모든 통제
추가적으로:
• 크리덴셜 바인딩은 다음을 사용하여 부당변경에 대한 보호를 제공해야만 한다.
a) 전자 서명 또는
b) 하드웨어 장치에 있는 크리덴셜을 위한 잠금 상태의 메커니즘
하드웨어만 가능
#3. 크리덴셜은 하드웨어 보안 모듈에 담겨있어야만 한다.
잠금 상태
#4. 하드웨어 장치에 담긴 크리덴셜은 생성 프로세스 마지막 상태에서 잠금 상태로 있어야만 한다.
인벤토리 추적
#5. 크리덴셜 또는 크리덴셜을 생성하는 수단이 하드웨어 장치에 담겨있다면, 하드웨어 장치는 물리적으로 안전하여야만 하며, 인벤토리를 지속적으로 추적하여야만 한다. 예를 들어, 개인화되지 않은 스마트 카드는 안전한 공간에 보관하여야 하며, 시리얼 번호를 기록하여 도난 및 인가되지 않은 크리덴셜 생성 시도로부터 보호하여야 한다.
적절한 크리덴셜 발행
#6. 크리덴셜 발행에는 공식화되고 문서화된 프로세스를 사용하여야만 한다.
#7. 다음 통제를 적용한다:
• #6의 모든 통제
추가적으로:
• 발행 프로세스는 크리덴셜이 적합한 개체 또는 인가받은 대리인에게 제공됨을 보장하는 메커니즘을 포함해야만 한다. 만약 크리덴셜이 대면으로 전달되지 않았다면, 이 메커니즘은 배송 주소가 실제 존재하고 개체와 법적인 연관성이 있는지를 확인하여야만 한다.
#8. 다음 통제를 적용한다
• #7의 모든 통제
추가적으로:
• 크리덴셜이 대면으로 전달되지 않았다면, 보안된 채널을 사용하여 전달되어야만 하며, 개체 또는 인가받은 개체의 대리인이 크리덴셜의 수령을 인정하는 영수증에 서명해야만 한다.
개체에 의한 활성화
#9. 크리덴셜 또는 크리덴셜을 생성하는 수단이 해당되는 개체의 통제 하에서만 활성화된다는 것을 보장하는 절차가 존재해야만 한다. 이 절차에 대해 구체적인 요구사항은 없다.
#10. 크리덴셜 또는 크리덴셜을 생성하는 수단이 해당되는 개체의 통제 하에서만 활성화된다는 것을 보장하는 절차가 존재해야만 한다. 이 절차를 통해 개체가 크리덴셜의 활성화와 바인딩했음을 증명해야만 한다(예, 도전-응답 프로토콜).
#11. 크리덴셜 또는 크리덴셜을 생성하는 수단이 해당되는 개체의 통제 하에서만 활성화된다는 것을 보장하는 절차가 존재해야만 한다. 이 절차는 다음을 따라야만 한다.
a) 개체가 크리덴셜의 활성화에 바인딩했있음을 증명(예, 도전-응답 프로토콜),
b) 정책에 의해 결정된 기간 내에서만 활성화를 허용
크리덴셜 보안 저장
#12. 다음 통제를 적용한다:
• 공유된 기밀에 기초하는 크리덴셜은 관리자와 접근을 요구하는 신청에만 접근을 제한시키는 접근 통제에 의해 보호되어야만 한다.
• 저장된 크리덴셜을 위한 보호 정책은 개체가 사용할 수 있도록 만들어진 크리덴셜의 사용에 대한 문서에 서술되어야만 한다.
#13. 다음 통제를 적용한다:
• #12의 모든 통제
추가적으로:
• 공유된 기밀 파일은 평문(plaintext)으로 된 비밀번호 또는 기밀을 함유하지 않아야만 한다. 공유된 기밀을 보호하기 위해 대안책을 사용할 수 있다.
#14. 다음 통제를 적용한다.
• #13의 모든 통제
추가적으로:
• 공유된 기밀에 기초하는 크리덴셜은 접근 통제에 의해서 보호되어야만 한다. 이 접근 통제는 공유된 기밀에 대한 접근을 관리자와 접근을 요구하는 애플리케이션에게로만 제한하여야 한다. 이런 공유된 기밀을 암호화하여야만 한다. 공유된 기밀을 위한 암호 키(encryption key)를 암호화하고 암호모듈(하드웨어 또는 소프트웨어)에 저장하여야만 한다. 공유된 기밀을 위한 암호 키는 인증 활동을 위해 요청되었을 경우에만 즉각 복호(decrypt)하여야만 한다.
• 개체 또는 개체가 인가한 대리인은 그들이 이러한 요구사항을 이해하고 요구사항에 따라 크리덴셜을 보호하는 것에 동의하도록 요구받아야만 한다.
#15. 다음 통제를 적용한다.
• #14의 모든 통제
추가적으로:
• 개체 또는 개체가 인가한 대리인은 그들이 크리덴셜의 저장을 위한 요구사항을 이해하고 그에 따라 크리덴셜을 보호하는 데 동의하는 문서에 서명하도록 요구받아야만 한다.
크리덴셜 보안 폐지 및 파기
#16. CSP는 크리덴셜(공유된 기밀에 기반한 것을 포함하여)을 각 LoA의 운영정책에 따라 특정 기간 내에 폐지 또는 파기(가능하다면)해야만 한다.
크리덴셜 보안 갱신
#17. 다음 통제를 적용한다.
• CSP는 크리덴셜의 갱신 및 대체를 위해 알맞은 정책을 수립해야만 한다.
• 만기되지 않은 현행의 크리덴셜 소유증명은 CSP가 갱신 및/또는 대체를 허가하기 전에 개체에 의해 증명되어야만 한다.
• 비밀번호는 최소한, 비밀번호의 견고성 및 재사용에 관한 CSP의 정책 요구사항을 충족시켜야만 한다.
• 통용되는 크리덴셜이 만기된 후에는, 갱신을 허용하지 않아야만 한다.
• 모든 교류는 보호받는 채널 내에서 일어나야만 한다.
#18. 다음 통제를 적용한다.
• #17의 모든 통제
추가적으로:
• 그들은 8.1.2.1 항에 따라 LoA2 신원 검증을 수행할 것이다(신원 검증: 정책 준수, 권위있는 정보).
기록 유지
#20. 각 크리덴셜의 등록, 이력 및 상태의 기록(폐지를 포함하여)은 CSP에 의해 보존되어야만 한다. 기록 유지의 기간은 CSP 정책에 명시되어야만 한다.
#21. 다음 통제를 적용한다.
• #20의 모든 통제.
• 각 기록에 대한 일련의 관리에 대해 공식화되고 문서화된 절차를 개발하여야만 한다.
8.3 인증 단계에 대한 위협 및 통제
8.3.1 인증 단계에서의 위협
인증 단계에서의 위협은 인증 도중 크리덴셜의 사용과 관련한 위협 및 인증과 관련한 일반적인 위협 두 가지를 모두 포함한다. 인증과 관련한 일반적인 위협은 다음을 포함하지만 이에 한정되지 않는다. : 악성 소프트웨어(예, 바이러스, 트로이 목마, 키 로거), 사회 공학기법(예, 숄더서핑, 하드웨어 및 PIN의 절도), 사용자 에러(예, 취약한 비밀번호, 인증 정보의 보호 실패), 거짓 부인, 인증 정보 전송 중 비인가된 도청 및/또는 수정, 서비스 거부, 및 절차적 취약점). 인증과 관련된 일반적인 위협에 대한 통제는 다중 인증의 사용 외에는 이 표준의 범위를 벗어난다. 이 절은 인증을 위한 크리덴셜의 사용과 관련된 위협에 집중하였고, 위협에 대해 설명하고, 위협의 종류에 따른 통제를 나열하였다.
LoA3 및 LoA4에서 다중 인증의 사용을 요구한 것 외에는, 인증 단계에서의 LoA에 대한 구체적인 통제를 기술하는 것이 적절하지 않다. 어떤 통제는 모든 맥락에 적용하기에 적절하지 않을 수 있다. 예를 들어, 사용자의 전자 잡지 구독료에 대한 접근과 관련된 인증에 대한 통제는 의사가 환자 기록에 접근할 때 사용되는 통제와 다를 것이다. 그러므로, 부당에 대한 위험과 중요도가 더욱 극심해지고 있으므로, CSP는 깊이 있게 보안을 고려해야 하는 것이 권장된다(예, 운영 환경, 지원, LoA에 있어 통제를 레이어링(layering)). 이는 위험 분석에 기반하여, 어떻게, 언제, 어떤 조합의 통제를 사용할 것인지 결정을 만드는 것은 시스템 디자이너에게 달려있다.
인증에 사용되는 크리덴셜에 대한 많은 위협이 존재한다. 표 8은 크리덴셜 사용에 대한 위협의 광범위한 카테고리의 나열이고, 위협을 설명하기 위해 구체적인 예시를 제공한다
표 8 — 인증 단계에서의 크리덴셜 사용에 대한 위협의 요약
| 위협 | 예시 |
| 일반적인 위협 | 인증과 관련된 일반적인 위협에 ICT의 모든 종류에서 흔히 보이는, 많은 종류의 위협이 포함된다. 예로 키 자동 기록기, 사회 공학기법, 사용자 에러이 포함된다. 다중 인증의 사용을 제외하고, 이러한 위협에 대한 통제는 이 표준의 범위에서 벗어난다. 다중 인증이 가능한 모든 일반 위협으로부터 보호할 수 없다는 것을 주의하여야 한다. |
| 온라인 추측 | 공격자가 크리덴셜의 가능값을 추정하여 반복적으로 로그온 시도를 한다. |
| 오프라인 추측 | 인증 거래가 아닌 다른 분석 중에, 크리덴셜 생성과 관련된 기밀이 유출된다. 비밀번호 크랙킹은 사전 공격과 같은 전수 공격 방법을 주로 사용한다. 사전 공격과 함께 공격자는 사전(또는 서로 다른 언어의 여러 사전)에 있는 모든 단어를 반복하는 프로그램을 사용하여 각 단어의 해시값을 계산하고 데이터베이스의 해쉬값 결과를 확인한다. 레인보우 테이블(rainbow tables)은 또다른 패스워드 크랙킹 방식이다. 레인보우 테이블은 평문/해쉬값의 쌍을 미리 계산한 표이다. 레인보우 테이블은 축소 기능을 사용하여 검색 공간을 줄여나가기 때문에 전수 공격보다 빠르다. 한번 레인보우 테이블을 생성하거나 구하면, 공격자는 여러 번 재사용할 수 있다. |
| 크리덴셜 복사 | 개체의 크리덴셜 또는 크리덴셜을 생성하는 수단이 불법적으로 복사한다. 예시로는 개인키의 비인가된 복사를 들 수 있다. |
| 피싱(Phishing) | 개체가 가짜 검증자에게 속아 교류하고, 개체를 가장하는 데 쓰일 수 있는 비밀번호나 개인 민감 정보를 유출하는 것. 예시로 개체가 사용자 이름과 비밀번호로 로그인하는 위조 웹사이트로 연결되는 메일을 받았을 때를 들 수 있다. |
| 도청 | 공격자가 인증 거래를 도청해 개체를 가장하여 차후 공격을 하는데 사용할 수 있는 정보를 포착하는 것을 칭한다. |
| 재전송 공격 | 개체가 RP에게 인증을 하는 메시지(합법적 개체와 RP간의)를 공격자가 포착하여 다시 재생한다. |
| 세션 하이재킹(Session Hijack) | 공격자는 개체와 검증자 간의 성공적인 인증 교환 후 자신을 개체-검증자 사이에 끼워 넣을 수 있다. 데이터 교환 세션을 통제하기 위해 공격자는 자신을 신뢰당사자에게 개체인 것처럼 제시할 수 있고, 그 반대도 가능하다. 공격자가 개체가 보낸 HTTP 요청을 나타내는데 사용되는 인증 쿠키 값을 도청하거나 또는 예측함으로써 이미 인증된 세션을 가로챌 수 있는 경우가 한 예가 될 수 있다. |
표 8 — 인증 단계에서의 크리덴셜 사용에 대한 위협의 요약(계속)
| 중간자 공격 | 공격자가 개체와 신뢰당사자 간에 사이에서 인증 프로토콜 메시지의 내용을 가로채고 변조할 수 있다. 일반적으로 공격자는 개체에게 신뢰 당사자인 것처럼 가장하고 동시에 검증자에게 개체인 것처럼 가장한다. 양 당사자와 동시에 능동적인 교환을 수행하는 것으로 공격자가 합법적 당사자가 보낸 인증 메시지를 사용하여고 다른 당사자에게 성공적으로 인증할 수 있도록 한다. |
| 크리덴셜 절도 | 공격자가 크리덴셜을 생성하거나 저장하는 장비를 훔친다. |
| 스푸핑과 위장(Spoofing And Masquerading) | 스푸핑과 위장(masquerading)은 공격자가 수행할 수 없는 활동을 수행하게 하기 위하여 공격자가 다른 개체를 가장하는 상황을 말한다. (예, 접근할 수 없는 자산으로의 접근을 획득한다) 이것은 개체의 크리덴셜을 사용함으로써 또는 자신에 개체라고 가장함으로써 이루어질 수 있다(예, 조작된 크리덴셜을 이용하여). 어떤 개체를 가장한 공격자가 “고무로 만든” 지문을 생성함으로써 하나 이상의 생체공학적 특성을 가장하는 경우, 특정 네트워크에 허가된 MAC 주소를 공격자의 장비가 방송하여 MAC 주소를 가장하는 경우, 또는 공격자가 온라인 소프트웨어 응용 또는 업데이트 다운로드에 대한 합법적인 소프트웨어 발행자인 척 가장하는 경우 등이 몇가지 예가 될 수 있다. |
8.3.2 크리덴셜 사용 시 위협으로부터의 보호에 필요한 LoA 통제
표 9는 LoA에 대한 크리덴셜 사용 위협에 대응하기 위해 필요한 통제를 식별한다.
표 9 — LoA 사용에 대한 위협 통제 요약(계속)
| 위협 | 통제 | 필요한 통제 | ||||
| LoAa | LoA1 | LoA2 | LoA3 | LoA4 | ||
| 일반b | 다중요소 인증 | #1 | #1 | |||
| 온라인 추측 | 강력한 패스워드(Strong Password) 크리덴셜 잠금(Credential Lock Out) 디폴트 계정 사용 금지 감사와 분석 |
#2 #3 #4 #5 |
||||
| 오프라인 추측 | 솔트를 사용한 해쉬 패스워드(Hashed Password With Salt) | #6 | ||||
| 크리덴셜 복사 | 위조 방지(Anti Counterfeiting) | #7 | ||||
| 피싱(Phishing) | 메세지에서 피싱 탐지 안티 피싱 관행 채택(Adopt Anti Phishing Practice) 상호 인증 |
#8 #9 #10 |
||||
| 도청 | 패스워드 전송 금지 인증 암호화 다른 인증 파라미터(Different Authentication Parameter) |
#11 #12 #13 |
||||
표 9 — LoA 사용에 대한 위협 통제 요약(계속)
| 위협 | 통제 | 필요한 통제 | ||||
| LoAa | LoA1 | LoA2 | LoA3 | LoA4 | ||
| 재전송 공격 | 다른 인증 파라미터(Different Authentication Parameter) 타임 스탬프(Timestamp) 물리적 보안 |
#13 #14 #15 |
||||
| 세션 하이재킹(Session Hijacking) | 세션 암호화 프로토콜 취약점 교정 암호화된 상호 핸드쉐이크(Cryptographic Mutual Handshake) |
#16 #17 #18 |
||||
| 중간자 공격 | 상호 인증 세션 암호화 |
#10 #16 |
||||
| 크리덴셜 절도 | 크리덴션 활성화 | #19 | ||||
| 스푸핑과 위장(Spoofing And Masquerading) | 코드 전자 서명 생체 탐지(Liveness Detection) |
#20 #21 |
||||
| 비고 위의 표에서 #1~#21의 식별자는 각 LoA에서의 보호하기 위해 요구되는 구체적인 통제에 상응한다. 이들 통제의 각각은 8.3.2.1 항에서 구체적으로 나타나있다. | ||||||
| a 이 통제는 위험평가에 의해 필수적인 것으로 여겨 적용되어야 한다. b 모든 일반적인 위협이 다중요소 인증으로 보호되지는 않는다. |
||||||
8.3.2.1 인증 단계에서 크리덴셜의 사용 시 위협에 대한 통제
인증 단계 중 크리덴셜 사용 시의 위협에 대한 다음의 통제는 표 10-6에 나열된 #1~#21의 번호에 상응한다.
다중요소 인증
#1. 둘 이상의 서로 다른 인증요소를 구현하는 크리덴셜을 사용해야만 한다(예, 당신이 아는 어떤 것과 당신이 가진 어떤 것의 결합).
강력한 패스워드
#2. 강력한 패스워드의 사용을 강제해야만 한다(예, 대문자, 소문자, 숫자 및 특수 문자의 혼합을 포함하는 사전에 나오지 않는 복잡한 문자열).
크리덴셜 잠금
#3. 패스워드 시도가 특정 회수 이상 실패한 후에는 계정 잠금이나 지연 메커니즘을 적용해야만 한다.
디폴트 계정 사용 금지
#4. 디폴트 계정명 및 패스워드(예, 제조사 설정)는 사용해서는 안된다.
감사와 분석
#5. 실패한 로그인 감사 증적을 유지하여 온라인 패스워드 추측 시도를 분석해야 한다.
솔트를 사용한 해쉬 패스워드
#6. 무차별 대입공격(brute force) 및 레인보우 테이블 공격을 지연시키기 위해 솔트와 함께 해쉬된 패스워드를 사용해야만 한다.
위조 방지
#7. 크리덴셜을 저장한 장비에는 위조방지 수단(예, 홀로그램, 마이크로 프린트)을 사용해야만 한다.
메시지에서 피싱 탐지
#8. 피싱 공격을 감지하기 위해 특별히 설계된 통제(예, 베이시안 필터, IP 블랙리스트, URL-기반 필터, 휴리스틱 및 지문 스킴 등)를 구현해야만 한다.
안티 피싱 관행 채택
#8. 개체를 피싱 공격으로부터 보호하기 위해 신뢰할 수 없는 원천으로부터의 이미지, 하이퍼링크를 사용할 수 없게 하고 이메일 클라이언트에 시각적 힌트 제공을 사용해야만 한다.
상호 인증
#9. 상호 인증을 사용해야만 한다.
패스워드 전송 금지
#11. 패스워드를 네트워크 상으로 전송하지 않는 인증 메커니즘(예, 커버로스 프로토콜)을 사용해야만 한다.
인증 암호화
#12. 네트워크 상에서의 인증 교환이 필수적이라면 데이터를 전송하기 전에 암호화해야만 한다.
다른 인증 파라미터
#13. 각 인증 거래에 대해 다양한 인증 파라미터(예, 일회용 패스워드, 세션 크리덴셜)를 사용해야만 한다.
타임 스탬프
#14. 각 메시지는 조작할 수 없는 타임 스탬프로 시간을 기록해야만 한다.
물리적 보안
#15. 물리적 보안 메커니즘(예, 변경 증적, 탐지 및 대응)을 사용해야만 한다.
세션 암호화
#16. 암호화된 세션을 사용해야만 한다.
프로토콜 취약점 교정
#17. 프로토콜의 취약점(예, TCP/IP)을 교정하기 위한 플랫폼 패치를 적용해야만 한다.
암호화된 상호 핸드쉐이크
#18. 암호에 기초한 상호 핸드쉐이크 교환(예, TLS)을 사용해야만 한다.
크리덴셜 활성화
#19. 크리덴셜을 사용하기 위해 활성화 기능(예, 크리덴셜을 저장한 하드웨어 장비에 PIM 또는 생체공학적 정보의 입력)을 요구해야만 한다.
코드 전자 서명
#20. 인가되지 않은 당사자가 변경한 소프트웨어를 다운로드 하는 것을 막기 위해 전자 서명의 원천이 신뢰할 수 있는지 검증해야만 한다.
생채 탐지
#21. 조작된 생체공학 특성이 사용되는지 판단하기 위해 생존성 탐지 기법을 사용해야만 한다.
9 서비스 보증 기준
신뢰할 수 있는 프레임워크 운영자가 이 프레임워크를 준수하고자 할 경우 그들은 지원하고자 하는 각 LoA의 요구사항을 만족하는 구체적인 기준을 수립해야만 한다. 또한 프레임워크의 준수를 주장하는 CSP를 그 기준으로 평가하여야 한다. 마찬가지로, CSP는 자신의 전반적인 업무 프로세스와 기술적인 메커니즘을 구체적인 기준에 따라 평가함으로써 이 프레임워크에 따라 서비스가 준수하는 LoA를 결정해야만 한다.
부속서 A
(규정)
크리덴셜 특성
a) 크리덴셜은 데이터다.
크리덴셜은 데이터를 저장하는 어떤 물리적인 컨테이너 또는 장비를 포함하지 않는다. 또한 크리덴셜을 만드는 데이터를 위한 생성기를 포함하지도 않는다. 그러므로 패스코드 생성기는 결코 크리덴셜의 일부가 아니며, 데이터에 서명을 할 수 있는 스마트카드나 디지털 서명을 생성하는 소프트워어 또는 글이 쓰여질 수 있는 종이 역시 크리덴셜의 일부가 아니다.
b) 크리덴셜은 신원 및/또는 자격의 증거가 되는 데이터를 포함해야만 한다.
그런 증거의 예는 다음과 같다
1) 알고 있는 어떤 것(예, 정적 패스워드)
2) 생체공학적 특징 또는 그와 같은 것의 한 표현. 또는
3) 가지고 있는 어떤 것으로 만들어진 데이터 (예, 패스코드 생성기로 만들어진 일회용 패스코드, 어떤 개체가 보유하고 있다고 가정되는 개인 키를 사용하여 하드웨어 또는 소프트웨어로 디지털 서명된 데이터)
c) 크리덴셜은 실제 크리덴셜의 일부를 구성하지는 않지만 식별 및 인증 프로세스에 유용한 다른 데이터를 동반할 수 있다.
이러한 데이터의 예에는 개체의 이름과 공개키 인증서가 포함된다. 이들의 어느 것도 신원 또는 자격의 증거로서 필수적이지 않지만 이들은 인증 프로토콜에 유용하다. 개체의 이름을 크리덴셜에 결부시키는 것은 신원을 확인한다. 공개키 인증서를 크리덴셜에 결부시키는 것은 개체의 신원 또는 자격에 대한 정보를 제공할 가능성뿐만 아니라 증거의 테스트를 돕는 정보를 제공한다.
d) 크리덴셜은 파생된 것일 수도 있다.
이런 경우, 그런 파생된 크리덴셜은 어떤 크리덴셜 집합으로부터 파생된 정보의 모음이 될 수 있으며, 일반적으로 인증을 위해 개체에 의해 생성되고 어떤 크리덴셜 검증자에게 보내진다.
예를 들어, 어떤 유형의 익명 인증에서 개체는 CSP가 발행한 크리덴셜을 인증에 사용되는 파생된 크리덴셜로 변환한다
e) 크리덴셜을 구성하는 모든 데이터가 비밀로 유지되어야만 하는 것은 아니다.
f) 크리덴셜은 개체의 인증, 식별 및 권한 부여(인가) 또는 이 세가지의 조합에 사용될 수 있다.
g) 크리덴셜은 그것이 진품이고, 특정한 목적에 대해 신뢰할만 하다고 받아들여지기 전에 먼저 검증되어야만 한다.
h) 크리덴셜을 검증하기 위해서는 몇 개의 단계를 거쳐야 한다. 이러한 단계의 예는 다음을 포함한다.
1) 크리덴셜의 진정성 검사 : 그것이 발행자라고 알려진 곳에서 비롯되었음을 보장하기 위하여
2) 크리덴셜의 유효성 및 신뢰성 검증(예, 크리덴셜 발행자로부터 신뢰할 수 있는 루트까지 직접적인 링크가 존재하는지 확인)
3) 수학/암호학의 계산적 정확성의 확인
i) 크리덴셜은 진품이라고 하더라도 모든 상황에서 유효한 것은 아니다(예, 크리덴셜은 선물 전화 칩 카드와 같은 스마트 카드에 들어 있는 크리덴셜은 진품이라고 하더라도 발행자의 시설을 사용한 통화에만 유효할 것이다).
부속서 B
(참고)
프라이버시와 PII 보호
특정 용도에 대한 특정 인증 접근방법의 적절성은 인증 효과성의 평가뿐만 아니라 위험 및 관련 조직의 위험 내성에도 또한 의존한다. 개체의 PII의 적절한 보호의 오용 또는 부족은 평판의 손상에서부터 법적 노출까지에 이르는 조직의 중대한 위험을 포함한다. 따라서 인증 목적의 PII의 이용과 그의 보호는 주의깊게 고려하고 저울질해야 한다. 이 부속서는 특정 인증 접근방법의 이용과 구현을 결정할 때 조직이 고려해야 하는 몇몇 프라이버시 고려사항에 관련된 정보와 지침을 제공한다.
개체가 개인일 때 대다수의 인증 접근방법은 다음 중 하나 이상에서 PII를 처리할 것이다.
a) 등록(enrolment) 프로세스 동안 신원 및 개체에 관련된 기타 정보를 수집, 증명 및 검증할 때
b) 개체의 크리덴셜의 생성, 발행, 관리 중
c) 개체가 크리덴셜을 사용하고 신뢰 당사자와 검증자가 이들을 검증할 때
프라이버시에 대한 부정적 영향을 제한하는 암호학적으로 강한 인증 접근방법(예, 익명 크리덴셜, 그룹 서명)이 많이 존재한다. 또한 강도가 증가된 보증 수준(예, LoA2에 대한 LoA4)은 반드시 그런 것은 아니지만 개인의 프라이버시에 나쁜 영향을 미칠 수 있음이 강조되어야 한다. 대다수는 선택된 인증 접근방법과 그것이 구현되는 방법에 의존한다. 이러한 결정을 하는 데 있어서 모든 조직은 그들의 자원을 보호하고 인가되지 않은 활동에 대하여 개체에 책임을 지워야 할 필요에 더하여 개체의 PII를 보호해야 할 필요를 주의깊게 고려해야 한다.
인증 접근방법의 대다수는 인증 상황에서 어떤 개체를 다른 가능한 개체로부터 분명하게 구분할 수 있는 명확한(distinguishing) 식별자의 사용을 포함한다. 명확한 식별자의 사용은 또한 계정 관리와 적절한 감사 증적의 유지와 같은 다른 다양한 목적에도 종종 필수적이다. 명확한 식별자 사용에 관련된 주된 프라이버시 우려는 명확한 식별자의 사용 자체에 관한 것이 아니라 많은 다른 설정에서 같은 식별자를 재사용하는 것에 관련된다. 예를 들어 단일 목적을 위해 할당된 계정 번호는 다양한 목적으로 사용되는 정부기관의 참조번호(예, 과세, 의료, 연금) 보다는 덜 민감한 것으로 간주된다. 특정 사법권역에서는 특정 식별자의 사용을 법적으로 제한할 수도 있다.
이상의 고려사항에서 보면 조직은 EAAF에서 설명된 단계 및 프로세스에 개체의 PII를 보호하기 위하여 효과적인 보호수단을 구현해야 한다. 특히 선택된 인증 접근방법은 PII 처리를 전반적으로 최소화하는 방식으로 설계되고 구현되어야 한다. 또한 다른 상황이나 도메인에서도 사용되는 명확한 식별자의 사용은 필수적이고 관련 사법권의 법이 허용하는 경우로 제한되어야 한다.
PII 보호를 위한 추가적인 ISO/IEC 지침은 다음의 두가지 원천에서 찾아볼 수 있다.
a) [b-ISO/IEC 29100] 는 세가지 주된 요소의 측면에서 기본적인 프라이버시 요구사항을 설명한다: (1) 개인 프라이버시의 보호 및 그 개인의 PII의 보호를 위한 법 규제 요구사항, (2) 특정 업무 및 유즈케이스 요구사항 및 (3) PII 개체의 개인 별 프라이버시 선호. [b-ISO/IEC 29100]은 다음의 기본적인 프라이버시 원칙을 설명한다: 동의 및 선택, 목적의 설명, 수집 제한, 이용, 보유 및 제공의 제한, 데이터 최소화, 정확성 및 품질의 개방성, 투명성 및 통지, 개인 참여 및 접근, 책임성, 보안 통제 및 준거성. 위협을 분석하기 위한 위험평가의 수행에 더하여 조직은 그들의 인증 접근방법에 대한 프라이버시 영향 평가를 수행하여 그들의 시스템 구성요소가 프라이버시 보호 방법의 측면에서 구체적인 주의를 필요로 하는지 여부를 평가해야 한다.
b) [b-ISO/IEC 29101]은 PII를 처리하는 ICT 시스템을 구현하기 위한 구성요소 집합이 제공된다. 이 아키텍처 프레임워크는 우려 및 몇가지 아키텍처 관점에서 표현된다. 구성요소 집합은 PII를 처리하는 ICT 시스템을 구현하기 위하여 제공된다. 이 프레임워크는 [b-ISO/IEC 29100]에서 다루는 프라이버시 원칙을 따르는 시스템 아키텍처를 구성하는데 사용하도록 만들어진 것이다.
PII 보호에 관한 요구사항, 원칙 및 시스템 설계에 대한 상세한 지침에 대해서는 상기의 표준들을 참고하라.
[b-ITU-T X.1252] Recommendation ITU-T X.1252 (2010), Baseline identity management terms and definitions.
[b-ITU-T Y.2702] Recommendation ITU-T Y.2702 (2008), Authentication and authorization requirements for NGN release 1.
[b-ITU-T Y.2720] Recommendation ITU-T Y.2720 (2009), NGN identity management framework.
[b-ITU-T Y.2721] Recommendation ITU-T Y.2721 (2010), NGN identity management requirements and use cases.
[b-ITU-T Y.2722] Recommendation ITU-T Y.2722 (2010), NGN identity management mechanisms.
[b-ISO/IEC 9798] ISO/IEC 9798:2010, Information technology – Security techniques – Entity authentication.
[b-ISO/IEC 18014-2] ISO/IEC 18014-2:2009, Information technology – Security techniques – Time-stamping services – Part 2: Mechanisms producing independent tokens.
[b-ISO/IEC 19790] ISO/IEC 19790:2012, Information technology – Security techniques – Security requirements for cryptographic modules.
[b-ISO/IEC 19792] ISO/IEC 19792:2009, Information technology – Security techniques – Security evaluation of biometrics.
[b-ISO/IEC 27000] ISO/IEC 27000:2012, Information technology – Security techniques – Information security management systems – Overview and vocabulary.
[b-ISO/IEC 27001] ISO/IEC 27001:2005, Information technology – Security techniques – Information security management system – Requirements.
[b-ISO/IEC 29100] ISO/IEC 29100:2011, Information technology – Security techniques – Privacy framework.
[b-ISO/IEC 29101] ISO/IEC 29101, Information technology – Security techniques – Privacy architecture framework.
[b-ISO/IEC 24760-1] ISO/IEC 24760-1:2011, Information technology – Security techniques – A framework for identity management – Part 1: Terminology and concepts.
[b-ISO/IEC 19790] ISO/IEC 19790:2012, Information technology – Security techniques – Security requirements for cryptographic modules.
[b-NIST SP800-36] NIST Special Pub 800-36 (2003), Guide to Selecting Information Technology Security Products.
<http://csrc.nist.gov/publications/nistpubs/800-36/NIST-SP800-36.pdf>
[b-NIST SP800-63] NIST Special Pub 800-63 (2006), Electronic Authentication Guideline Version 1.0.2.
<http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf>
[b-AGGPKI] Australian Government Gatekeeper Public Key Infrastructure. http://www.gatekeeper.gov.au/
[b-DuD] Van Alsenoy B., and De Cock, D. (2008), 'Due processing of personal data in eGovernment? A Case Study of the Belgian electronic identity card', Datenschutz und Datensicherheit, Vol.32, No.3, pp.178-183.
[b-EoI] New Zealand Standard: Evidence of Identity Standard Version 2.0, 2009. <http://www.dia.govt.nz/EOI/pdf/EOIv2.0.pdf>
[b-ENISA] ENISA, Mapping (Interoperable Delivery of European e-government services to public Administrations, Businesses and Citizens) IDABC Authentication Assurance Levels to SAML v2.0.
[b-IAF] Kantara Initiative Identity Assurance Framework v2.0. http://kantarainitiative.org/confluence/display/GI/Identity+Assurance+Framework
[b-MOV] Menezes, A., van Oorschot, P., and Vanstone, S. (1997), 'Handbook of Applied Cryptography', pp. 3-4.
<http://www.cacr.math.uwaterloo.ca/hac/>
[b-NeAF] The National e-Authentication Framework.
<http://www.finance.gov.au/e-government/security-and-authentication/authentication-framework.html>
[b-OECD] OECD (2007), OECD Recommendation on Electronic Authentication and OECD Guidance for Electronic Authentication.
<http://www.oecd.org/dataoecd/32/45/38921342.pdf>
[b-OMB] OMB M-04-04 (2003), e-Authentication Guidance for Federal Agencies
<http://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdf>
[b-PEA] Industry Canada (2004), Principles for Electronic Authentication: A Canadian Framework.
<http://strategis.ic.gc.ca/epic/site/ecic-ceac.nsf/en/h_gv00240e.html>.
KS X ITUT X1254:2012
해 설
이 해설은 본체 및 부속서(규정)에 규정한 사항, 부속서(참고)에 기재한 사항 및 이들과 관련된 사항을 설명하는 것으로 표준의 일부는 아니다.
1 제정의 취지
현재 핀테크 및 전자정부 서비스를 위해서는 정보의 민감도와 서비스의 중요성에 따라 다양한 등급의 인증 수준에 근거한 인증 서비스를 제공할 필요가 있다.
따라서 이 표준은 핀테크, 인터넷 은행 등의 비대면 본인확인, 다중요소 인증을 위한 기반 프레임워크로 활용하기 위해 제정하였다.
2 주요 내용
이 표준은 주어진 상황에서 개체 인증 보증을 관리하기 위한 프레임워크를 제공한다. 특히
— 개체 인증 보증의 4 개 수준을 명시한다.
— 개체 인증 보증의 각 4 개 수준을 달성하기 위한 기준과 지침을 명시한다
— 4단계의 LoA에 기초한 인증의 결과를 교환하기 위한 지침을 제공한다.
— 인증 위협을 완화하기 위해 사용되어야 하는 통제에 관한 지침을 제공한다
■ 관련 자료
■ 링크
원본 자료의 관련 링크는 아래와 같다.
https://www.data.go.kr/data/15105036/fileData.do
과학기술정보통신부 국립전파연구원_방송통신표준_개체 인증 보증 프레임워크_20171227
이 표준은 2012년에 발행된 ITU-T X.1254 Entity authentication assurance framework를 기초로 기술적인 내용 및 대응국제표준의 구성을 변경하지 않고 작성한 방송통신표준이다.<br/><br/>이 표준은 주어진 상황
www.data.go.kr
https://link.coupang.com/a/ceoCYp
브라더 잉크젯 복합기 DCP-T720DW - 잉크젯 복합기 | 쿠팡
현재 별점 4.8점, 리뷰 1288개를 가진 브라더 잉크젯 복합기 DCP-T720DW! 지금 쿠팡에서 더 저렴하고 다양한 잉크젯 복합기 제품들을 확인해보세요.
www.coupang.com
https://link.coupang.com/a/bY9wBy
미니소화기 파이렉스 FIREX 스프레이식 소화기 가정용 휴대용 차량용 최신제품 당일발송 - 소화기
현재 별점 4.7점, 리뷰 139개를 가진 미니소화기 파이렉스 FIREX 스프레이식 소화기 가정용 휴대용 차량용 최신제품 당일발송! 지금 쿠팡에서 더 저렴하고 다양한 소화기/거치대 제품들을 확인해보
www.coupang.com
https://link.coupang.com/a/bXy1hr
LG전자 시네빔 HU710PB 2024신모델 큐브 4K 빔프로젝터 Qube - 빔/프로젝터 | 쿠팡
쿠팡에서 4.9 구매하고 더 많은 혜택을 받으세요! 지금 할인중인 다른 15 제품도 바로 쿠팡에서 확인할 수 있습니다.
www.coupang.com
"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."
■ 기준 날짜
2025.6.1
'공공 데이터' 카테고리의 다른 글
| [공공데이터] 과학기술정보통신부 국립전파연구원 방송통신표준 공통경보프로토콜 (0) | 2025.06.07 |
|---|---|
| [공공데이터] 과학기술정보통신부 국립전파연구원 방송통신표준 스마트폰 보안관리 제품 보안 요구사항 (0) | 2025.06.07 |
| [공공데이터] 경기도 하남시 불법주정차무인단속시스템 단속 건수 (0) | 2025.06.07 |
| [공공데이터] 강원특별자치도 춘천시 인구 현황 (0) | 2025.06.07 |
| [공공데이터] 경상북도 김천시 착한가격업소 (0) | 2025.06.07 |
