PKI 인증서를 사용한 웹 인증

개인 키 / 공개 키와 같은 개념적인 관점, 즉 인증서에 서명하는 데 해시 및 암호화 사용, 거래 또는 문서의 디지털 서명 등 PKI를 개념적 관점에서 합리적으로 잘 이해합니다. 또한 openssl이있는 프로젝트에서 작업했습니다. C 라이브러리는 통신 및 인증 보안을 위해 인증서와 함께 사용되었습니다. 또한 openssl 명령 줄 도구에 매우 익숙합니다.

그러나 웹 기반 PKI 지원 프로젝트에 대한 경험이 거의 없으므로이를 더 잘 이해하기 위해 개인 프로젝트를 디자인하고 코딩하려고합니다.

요구 사항

이것은 은행을위한 웹 사이트입니다. 모든 인터넷 뱅킹 사용자는 알려진 CA (verisign, Thawte, entrust 등)에서 발급 한 모든 인증서를 사용할 수 있습니다. 은행은 사용자의 인증서를 조달 할 책임이 없습니다. 이 인증서는 은행 웹 사이트 인증에 사용됩니다. 플랫폼 / OS 등은 여전히 ​​고정되어 있지 않습니다.

디자인

인증을 수행하는 가장 좋은 방법이 궁금합니다.

1. Apache에 양방향 ssl을 사용하는 방법이 있다는 것을 알았습니다.이 경우 웹 사이트를 탐색하면 자동으로 사용자에게 인증서를 요청합니다. 그러나 신뢰할 수있는 CA가 인증서에 서명했는지 여부와 인증서의 제목 줄 목록에 속하는지 여부 만 확인하기 때문에 이것이 충분한 지 확실하지 않습니다. 그러나 이것은 충분하지 않습니다. 은행 사용자 ID를 인증서와 연관시킬 수 있어야하기 때문에 은행 사건의 경우.

2. IIS는 Active Directory의 각 사용자에 대해 인증서를 저장할 수있는 방법을 가지고 있습니다. 이것이 MSDN 기사를 거의 읽지 않아서 이해 한 것입니다. IIS에서 양방향 SSL을 켜고 사용자가 웹 사이트를 탐색하려고하면 IIS는 승인 된 CA 목록과 함께 브라우저에 요청을 보내고 브라우저는 사용자가 자신의 인증서 저장소에서 적절한 인증서를 선택하여 보내도록합니다. 백엔드. IIS가 두 가지 작업을 수행한다고 가정합니다.

   • 사용자에게 인증서에 해당하는 개인 키가 있는지 확인하십시오 (커버 협상에 따라).
   • AD 사용자 인증서 매핑을 기반으로 IIS는 사용자 이름을 응용 프로그램에보고합니다.

3. 웹 서버에 따라 암호화 기능을 호출하여 인증을 명시 적으로 수행하십시오.

   • 인증서를 업로드하는 사용자 화면을 표시하면 응용 프로그램은 사용자에게 인증서에 해당하는 개인 키가 있는지 확인합니다 (인증서를 사용하여 일부 문자열에 서명하도록 프런트 엔드에 요청).
   • 응용 프로그램에는 각 사용자를 자신의 사용자 ID에 매핑 할 수있는 일부 데이터가 저장되어있는 데이터베이스가 있습니다. 이것은 아마도
   • 각 사용자 ID에 해당하는 전체 인증서
   • 각 사용자 ID에 해당하는 CA 및 인증서 일련 번호

나는 일반적으로 사용되는 방법이 궁금합니다. 모범 사례는 무엇입니까? # 3으로 가야한다면 가장 좋은 방법은 무엇입니까?

스마트 폰 앱에서도 쉽게 작동 할 수있는 것이 추가 보너스가 될 것입니다.

최신 정보

답변 중 일부가 잘못 이해되어 있음을 나타내는 것처럼 보이기 때문에 "인증 부분을 직접 코딩하십시오"라는 내용을 명확하게 설명하겠습니다.

이것은 내가 암호화 물건을 직접 쓰는 것을 의미하지는 않습니다. IIS 또는 다른 웹 서버에 의존하지 않고 암묵적으로 암호화 루틴을 실제로 호출한다는 것을 의미합니다.

문제별로 문제에 답하고 싶었지만 주제별로이 주제를 다룰 것입니다.

인증 / 인증

좋아, 우선 먼저. 예를 들어, 둘 다 필요합니다.

• 인증 -사용자가 자신이 누구인지를 증명합니다. 암시 된 개인 키 증명을 인증으로 사용하여 PKI를 선택했습니다.
• 승인 -사용자가 자신이 할 수있는 것에 연결. 이것은 로그인과 허용 된 계정에 액세스하는 연결점입니다. 계정과 계정 액세스 기능에 대한 인증서 매핑이 인증입니다.

인증 측면에서는 사용자의 주제 DN을 은행 계좌에 연결하는 프로세스를 파악하는 데 문제가 있습니다. 거래의 중력을 감안할 때, 당신은 확실히 이것에 대한 강력한 프로세스를 원하고 있으며, 여기에 올바른 방법은 없습니다. 정책에 따라이를 수행하는 방법을 알아 보려면 은행 및 변호사와 상담해야합니다.

SSL, 클라이언트 / 서버 인증, 개인 키 증명

SSL 프로토콜에는 항상 서버 인증이 포함되며 클라이언트 측 인증을위한 추가 선택적 설정이 있습니다. Apache는 PKI에 의한 클라이언트 인증을 추가하는 설정을 제공하고 신뢰할 수있는 CA 목록으로 프로비저닝 할 수 있다는 점에서 # 1과 맞습니다. PKI를 통한 클라이언트 인증이 필요한 SSL 세션을 설정하는 동안 개인 키 증명이 제공됩니다.

옵션 # 1 또는 옵션 # 2가이를 제공합니다. Apache와 IIS는이 방법으로 구성 할 수 있습니다. 현명한 모범 사례는 귀하의 솔루션을 롤링하는 것보다 하나를 취하는 것입니다. # 3은 "자신의 암호를 작성하지 마십시오"규칙과 밀접하게 관련되어 있습니다. 트랜잭션을 인증 된 SSL 세션의 존재와 연결할 수 있다고 가정하면 자신의 롤을 할 이유가 없습니다.

또한 옵션 # 1 또는 옵션 # 2에서 전체 인증서를 얻을 수있는 방법이 있으며 여기서 인증서의 어느 부분 으로든 갈 수 있습니다. 일반적으로 주제 DN 및 / 또는 인증서 일련 번호는 권한 부여 목적으로 사용자의 신원을 확인하는 데 사용됩니다.

"공통 사용"의 관점에서 보면 모든 주요 웹 서버는 매우 일반적입니다. IIS, Apache, Tomcat 등은 클라이언트 인증 SSL로 구성 할 수 있습니다. 거기에서의 결정은 대체로 전반적인 구현을 기반으로합니다. 주요 웹 서버는 모두 SSL 세션에서 제공되는 인증서에 액세스 할 수있는 방법을 가지고 있었으므로보다 자세한 검증이 필요합니다.

인증서 확인 애드온

최소한 다음을 수행해야합니다.

• SSL 세션 설정
• 인증서를 가져옵니다 (대부분의 웹 서버는 인증서의 서명과 개인 키 증명을 확인합니다)
• 인증서 유효 날짜 확인 (웹 서버에서 제공되지 않은)
• 이 인증서가 액세스 할 수있는 계정에 대한 권한 확인 수행

뱅킹의 위험이 높기 때문에 인증서의 해지 상태를 확인할 수도 있습니다. 사용자의 개인 키를 분실하거나 도난당한 경우 인증서를 해지해야합니다.

IIS는 OCSP 또는 CRL 확인을위한 훅을 가지고있을 수 있습니다. 더 포괄적 인 (손 잡기!) 유형의 시스템 인 경향이 있지만, 나는 머리 꼭대기를 기억하지 못합니다. 또한 Microsoft 제품을 사용하도록 강요할지 모르겠습니다. Apache의 경우 OCSP / CRL 검사를 코딩하거나 추가해야합니다. SSL 세션을 설정하는 동안 후크가 있다고 생각합니다. 일반적 으로이 확인은 SSL 세션을 설정할 때 한 번 수행됩니다.

권한 부여

# 1과 # 2의 경우 IIS에는 SSL 세션에서 제공되는 인증서를 AD 리포지토리에 연결하는 기능이 내장되어 있습니다. Microsoft가 더 많은 제품을 쉽게 구매하고 사용할 수 있도록하기 위해 추가 비용을들이는 경우 중 하나입니다. :) IIS가이 질문의 범위를 벗어나서 즉시 기억할 수없는 AD와 어떻게 연결되는지에 대한 뉘앙스가 있습니다. 나는 IIS와 AD로 꽤 미친 것들을 해왔으며, 일반적인 생각은 AD 저장소에서 인증서를 기반으로 사용자 이름을 가져 오는 것과 같이 비교적 간단한 작업을 수행하는 동안 괜찮을 것입니다. 더 복잡한 데이터 스토리지 문제, 이상한 AD 조회, 특히 PKI를 사용하여 미쳤지 만 합법적 인 문제에 직면하게되면

IIS를 사용하더라도 여전히 AD 구조에 추가하거나 사용자 이름을 은행 계좌에 연결하는 것이 필요합니다. 일반적으로 뱅킹에서 사용자는 여러 계정을 가지고 있습니다. 그리고 2 명의 사용자가 공동 계정을 가질 수 있으므로이 관계는 다 대다 관계입니다.

# 1-네, 당신은 당신의 자신의 조회를 작성해야합니다. 다음을 코딩해야합니다.-인증서를 사용자와 사용자를 사용자 은행 계좌에 연결하는 데이터베이스 또는 LDAP 계층. 인증서의 보장 된 고유 부분은 일련 번호 + 발급자 DN입니다. 종종 주제 DN은 작동하지만 모든 PKI 시스템에서 보장되지는 않습니다.

이것이 일반적으로 Apache에서 고급 인증을 위해 PKI를 사용하는 개발자가 수행하는 방식입니다. 이러한 여러 시스템에서 일한 후에도 권한 부여가 쉽게 재사용되는 경우가 발생하지 않았으므로 실제로 큰 마이너스로 간주하지는 않습니다. 결코 쉬운 일이 아닙니다.

SSL 세션을 생성하는 데 사용하는 모든 응용 프로그램 / 웹 서버의 기본 기능을 사용하는 것이 좋습니다. 그러면 인증서 쿼리를 사용하여 브라우저에서 서버 설정을 표준 모범 사례 방식으로 수행 할 수 있습니다. 여기에서 Apache를 사용하면 자체 권한 부여 시스템을 롤업해야합니다. IIS는 이것이 어떻게 작동하는지에 대한 Microsoft의 아이디어를 제공합니다.

알려진 문제점

여러 가지 브라우저 테스트를 수행하십시오. 해마다 브라우저마다 브라우저에서 SSL 세션 처리가 필요합니다. SSL 세션을 일련의 웹 페이지 요청에 올바르게 연결하고 로그 아웃이 올바르게 처리되도록하는 것이 가장 큰 관심 영역입니다. 그리고 서버와 브라우저 소프트웨어 모두와 많은 관련이 있습니다. SSL은 작동 할 때 IE가있을 수 있지만 다른 모든 사람이있을 수 있지만 작동 할 때 충분히 안정적입니다.

특히, 마지막으로이 작업을 수행 할 때 강제 코딩 및 세션 시간 초과 문제가 큰 문제였습니다.

스마트 폰

좋은. 운. 내가 말할 수있는 모든 것입니다. 나는 전혀 모바일 앱 개발자가 아니지만 지금까지의 인상은 일반적인 스마트 폰에서 PKI 인증서 처리가 하위 수준이거나 존재하지 않는다는 것입니다.

나는 틀린 것으로 증명되고 싶습니다.

개인 인증서는 인증서를 정기적으로 갱신하는 데 효과적이며 (이 프로세스는 상당히 강력한 프로세스 임) 고객이 선호하는 "암호없는"인증으로 구현할 수 있습니다.

그러나 그것이 실패한 곳은

• 인증 서당 비용
• 최신 브라우저와의 호환성
• 최종 사용자가 인증서를 추출하고 개인 키를 안전하지 않게 저장

sha-2 서명이있는 최신 개인 인증서는 iPad의 Safari 및 많은 최신 브라우저에서 작동하지 않습니다. 인증 기관에서 생각한 것처럼 개인 인증서가 실제로 생성되지 않았기 때문입니다. 30,000 개의 인증서 (우리가하는 일)를 발행하면 일부 하드웨어 토큰 유형과 동일한 인증 서당 비용이 발생합니다.

고객이 자신의 인증서를 찾을 수 있도록하는 전략은 실제로 유효하지 않습니다. 요즘 개인 인증서 공급자를 찾기는 어렵고 비용이 많이 들기 때문에 비즈니스 사례가 제대로 작동하는지 확인해야합니다.

좋아, 여기에 많은 일이 있습니다. 우선, 클라이언트 인증서 인증이 끝점에서 지원되지 않으면 쓸모가 없습니다. 따라서 Intrepidus의 스마트 폰 앱에 대한 클라이언트 인증 기본 사항을 다루는 훌륭한 게시물이 있습니다 .

다음으로 자체 인증 루틴을 코딩하지 말 것을 강력히 제안합니다. 이것을 처리하는 많은 검증 된 라이브러리가 있습니다. 인증을 위해 성숙한 라이브러리를 사용하여 기능 및 보안 버그를 절약 할 수 있습니다. 이를 위해 신중하고 성숙한 라이브러리를 사용하는 것이 가장 좋습니다.

다음 모범 사례는 클라이언트 : 인증서 매핑을 처리하기 위해 디렉토리를 사용하는 것입니다. 따라서 AD 또는 LDAP를 살펴볼 것입니다. 앞에서 언급했듯이 Windows와 IIS는이를 매우 원활하게 만듭니다. IIS.net에는 IIS에서 인증서 매핑 을 구성 하는 방법이 잘 설명되어 있습니다 .

아파치와 함께 사용한다면, 이것은 쉬운 일이 아닙니다. mod_authz_ldap 은 클라이언트 인증서 매핑을 수행하는 것처럼 보이지만 개인적으로는 사용하지 않았습니다.

따라서 실제로 이와 같은 것을 구현하는 물류를 제공합니다. 사용자 인증서에 서명하지 않았으므로 사용자가 인증서를 제출하고 앱이 디렉토리에 인증서를 게시하도록하려면 엄격한 프로세스가 필요합니다. 암호 인증과 문자 메시지 또는 신뢰할 수있는 번호로 전화를 걸면 두 가지 요소를 원합니다. 인증서가 자신의 계정에 추가되었음을 알리기 위해 사용자에게 이메일을 보내려고합니다. 사용자가 앱의 계정 관리 페이지를 통해 사용자 인증서 매핑을 제거하도록 할 것입니다.

2 단계를 피하기 위해 신뢰할 수있는 장치에 쿠키를 설정하기 위해 Google과 Facebook이하는 일을 살펴 보겠습니다. 인증서 전용 인증을 허용하기 전에 2 단계로 인증 된 새 장치가 있습니다.

또한 해지되는 사용자 인증서를 처리하는 방법에 대해서도 생각합니다. 이는 외부 CRL (인증서 해지 목록)을 확인하는 것을 의미합니다. 클라이언트 인증서에 CRL 배포 지점이 정의되어 있지 않으면 어떻게합니까? 소수의 CRL 만 사용되므로 사용자가 로그인 할 때마다 또는 작업의 일부로 예약 된 CRL을 확인합니까?

실제로 이것은 사용자 인증서가 손상되지 않았다는 것을 어떻게 신뢰할 수 있는지, 인증서 X를 사용자 Y에 매핑 할 수 있다는 것을 어떻게 신뢰할 수 있는지에 달려 있습니다.