상호의 TLS (mTLS) 인증은 사용자와 IoT 기기를 모두 인증하기 위한 안전한 프레임워크를 만듭니다. 이 가이드에서는 m을 구현하는 방법을 안내합니다.TLS 클라이언트와 서버 간의 안전한 양방향 인증을 보장합니다.
퀵 스타트 가이드
상호 설정 TLS 간단한 프로세스를 따릅니다. 먼저 필요한 서버 및 클라이언트 인증서를 생성합니다. 다음으로 클라이언트 인증서를 요구하도록 서버를 구성합니다. 그런 다음 클라이언트를 인증서로 설정하고 적절한 인증서 검증을 구현합니다. 마지막으로 연결을 테스트하여 모든 것이 예상대로 작동하는지 확인합니다.
단방향 및 상호 SSL /TLS 인증
SSL /의 정의 기능 중 하나TLS 프로토콜은 컴퓨터 네트워크 (예 : 인터넷)에서 익명의 당사자를 인증하는 역할입니다. 공개적으로 신뢰할 수있는 웹 사이트를 방문 할 때 SSL /TLS 증명서, 브라우저는 웹 사이트 소유자가 SSL.com과 같은 신뢰할 수있는 타사 인증 기관 (CA)에 해당 도메인 이름에 대한 제어를 성공적으로 입증했는지 확인할 수 있습니다. 이 확인이 실패하면 웹 브라우저는 해당 사이트를 신뢰하지 않도록 경고합니다. 대부분의 애플리케이션에서 SSL /TLS 이런 종류의 사용 단방향 인증 클라이언트에 서버의; 익명 클라이언트 (웹 브라우저)는 공개적으로 신뢰할 수있는 SSL을 제공하는 웹 서버와 암호화 된 세션을 협상합니다.TLS 자신을 식별하는 인증서 SSL /TLS 악수:
상호 인증, 두 서버 모두 and SSL /의 클라이언트TLS 세션이 인증되고 가능하며 일부 상황에서 매우 유용 할 수 있습니다. 상호 인증에서 서버가 핸드 셰이크 중에 인증되면 CertificateRequest 클라이언트에 메시지. 클라이언트는 인증을 위해 서버에 인증서를 보내 응답합니다.
상호를 통한 클라이언트 인증 TLS 다음을 포함하는 인증서가 필요합니다. Client Authentication (1.3.6.1.5.5.7.3.2) EKU (확장 키 사용)는 클라이언트 장치에 설치됩니다. SSL.com의 모든 이메일, 클라이언트 및 문서 서명 인증서 클라이언트 인증을 포함합니다.
세부 구현 가이드
상호 이해 TLS
전통적인 TLS 서버 인증 및 암호화를 제공하지만 상호 TLS 두 당사자가 디지털 인증서를 제시하도록 요구함으로써 더 나아갑니다. 이 양방향 검증은 서버 진위성을 보장하고, 클라이언트 인증을 가능하게 하고, 암호화된 통신 채널을 설정하고, 중간자 공격을 방지합니다. 그 결과 민감한 애플리케이션과 IoT 기기 통신에 적합한 매우 안전한 연결이 제공됩니다.
사전 조건
구현을 시작하기 전에 OpenSSL 또는 유사한 인증서 관리 도구에 액세스할 수 있는지 확인하십시오. 웹 서버는 다음을 지원해야 합니다. TLS, 그리고 당신은 다음에 대한 액세스가 필요합니다. 인증 기관 (CA) 또는 개인 CA를 만드는 기능. 클라이언트도 인증서 기반 인증을 지원해야 합니다.
1단계: 인증서 생성 및 관리
서버 및 클라이언트 인증에 필요한 인증서를 생성하는 것으로 시작합니다. 서버 인증서 설정에는 개인 키 생성이 필요합니다. 인증서 서명 요청 생성, CA에 인증서 서명을 합니다.
# 서버 개인 키 생성
하려면 openssl 겐르사 -아웃 서버 키 2048
?
# 서버 인증서 서명 요청 생성 (CSR)
하려면 openssl REQ -새로운 -키 서버 키 -아웃 서버.csr
?
# CA로 서버 인증서에 서명하세요
하려면 openssl x509 -요구 ~에서 서버.csr -캘리포니아 ca.crt -CA키 ca.키 -CAcreateserial -아웃 서버.crt
클라이언트 인증서의 경우 유사한 프로세스에 따라 고유한 자격 증명을 만듭니다.
# 클라이언트 개인 키 생성
하려면 openssl 겐르사 -아웃 클라이언트.키 2048
?
# 클라이언트 생성 CSR
하려면 openssl REQ -새로운 -키 클라이언트.키 -아웃 클라이언트.csr
?
# 클라이언트 인증서에 서명하세요
하려면 openssl x509 -요구 ~에서 클라이언트.csr -캘리포니아 ca.crt -CA키 ca.키 -CAcreateserial -아웃 클라이언트.crt
2단계: 서버 구성
서버는 클라이언트 인증서를 요구하고 검증하도록 구성되어야 합니다. 다음은 Nginx에 대한 구성 예입니다.
섬기는 사람 {
들어 443 SSL;
서버 이름 예제.com;
?
ssl_certificate /경로/대상/섬기는 사람.crt;
SSL_certificate_key /경로/대상/섬기는 사람.열쇠;
ssl_클라이언트_인증서 /경로/to/ca.crt;
ssl_verify_client 의 위에;
SSL_프로토콜 TLSv1.2 TLSv1.3;
SSL_ciphers 높은:!NULL:!MD5;
ssl_prefer_server_ciphers 의 위에;
}
Apache 서버의 경우 다음 구성을 사용하세요.
<VirtualHost *:443>
서버 이름 example.com
SSL엔진 on
SSL인증서 파일 /경로/서버.crt
SSL인증서키파일 /path/to/server.key
SSLCA 인증서 파일 /경로/to/ca.crt
SSLVerify클라이언트 필요
SSL확인심도 1
3단계: 클라이언트 구현
브라우저 기반 인증은 클라이언트 인증서를 브라우저의 인증서 저장소로 가져와야 합니다. 각 브라우저는 이 프로세스를 다르게 처리하지만 일반적으로 보안 또는 개인 정보 보호 설정에서 옵션을 찾을 수 있습니다.
IoT 기기의 경우 코드에서 인증서 기반 인증을 구현해야 합니다. Python의 requests 라이브러리를 사용한 예는 다음과 같습니다.
import 요청
?
클라이언트_인증서 = ('클라이언트.crt', '클라이언트.키')
CA 인증서 = 'ca.crt'
?
응답 = 요청.얻을('https://example.com',
인증서=클라이언트_인증서,
확인=CA 인증서)
4단계: 인증서 검증
적절한 인증서 검증은 보안에 필수적입니다. 구현은 인증서 체인 무결성을 검증하고, 만료 날짜를 확인하고, 해지 상태를 검증하고, 적절한 키 사용을 보장해야 합니다. 다음은 구현 예입니다.
에 암호 법 import x509
에 암호 법.유해 물질.백엔드 import 기본 백엔드
?
def 인증서 검증(인증서 경로):
과 열 수(인증서 경로, '알비') as 인증서_파일:
인증서 데이터 = 인증서_파일.읽기()
인증서 = x509.로드_pem_x509_인증서(인증서 데이터, 기본 백엔드())
if 인증서.유효하지 않음 < 날짜 시간.날짜 시간.지금() :
모집 값 오류("인증서가 만료되었습니다")
시도:
키 사용법 = 인증서.확장.클래스를 위한 확장 기능 얻기(x509.키 사용)
if 지원 키 사용법.가치.디지털 서명:
모집 값 오류("디지털 서명에 유효하지 않은 인증서입니다.")
외 x509.확장.확장자를 찾을 수 없음:
모집 값 오류("필수 키 사용 확장을 찾을 수 없습니다")
상호 인증 사용 사례
상호의 TLS 인증은 최종 사용자를 인증하고 컴퓨터 네트워크에있는 장치의 상호 인증에 모두 사용할 수 있습니다.사용자 인증
기업 및 기타 조직은 디지털 클라이언트 인증서를 직원, 계약자 및 고객과 같은 최종 사용자에게 배포 할 수 있습니다. 이러한 클라이언트 인증서는 Wi-Fi, VPN 및 웹 응용 프로그램과 같은 회사 리소스에 액세스하기위한 인증 요소로 사용할 수 있습니다. 기존 사용자 이름 / 암호 자격 증명 대신 (또는 추가로) 사용하면 상호 TLS 몇 가지 보안 이점을 제공합니다.- 상호의 TLS 인증은 다음과 같은 전술을 통해 자격 증명 도용에 취약하지 않습니다. 피싱. Verizon 2020 데이터 유출 사고 조사 보고서 데이터 침해의 거의 22/XNUMX (XNUMX %)이 피싱으로 인한 것임을 나타냅니다. 피싱 캠페인은 사용자의 클라이언트 인증서에 대한 개인 키가 아니라 웹 사이트 로그인 암호와 같이 쉽게 수집되는 자격 증명을 위해 나옵니다. 피싱에 대한 추가 방어 수단으로 SSL.com의 모든 이메일, 클라이언트 및 문서 서명 공개적으로 신뢰할 수있는 인증서 포함 S/MIME 서명되고 암호화 된 이메일 용.
- 상호의 TLS 취약한 암호 위생이나 암호에 대한 무차별 대입 공격으로 인해 인증이 손상 될 수 없습니다. 사용자에게 강력한 암호를 만들도록 요구할 수 있지만 50 개의 서로 다른 웹 사이트에서 동일한 "보안"암호를 사용하지 않거나 스티커 메모에 작성하지 않았는지 어떻게 알 수 있습니까? ㅏ 2019 Google 설문 조사 52 %의 사용자가 여러 계정에 대해 암호를 재사용하고 13 %의 사용자가 동일한 암호를 모든 그들의 계정.
- 클라이언트 인증서는 명확한 신뢰의 사슬, 중앙에서 관리 할 수 있습니다. 상호 TLS, 어떤 인증 기관 (CA)이 사용자의 자격 증명을 발급했는지 확인이 인증 프로세스에 직접 적용됩니다. SSL.com 온라인 관리 도구, SW API, SCEP와 같은 표준 프로토콜에 대한 액세스를 통해 이러한 자격 증명을 손쉽게 발급, 갱신 및 취소 할 수 있습니다!
- 하나 또는 몇 개의 인증서 만 필요한 개인 또는 조직은 주문할 수 있습니다. 이메일, 클라이언트 및 문서 서명 인증서 SSL.com의 단품 메뉴.
- SCEP, EST 및 CMP와 같은 프로토콜을 사용하여 회사 소유 및 BYO 장치에 대한 클라이언트 인증서 등록 및 갱신을 자동화 할 수 있습니다.
- 다량의 인증서가 필요한 고객의 경우 당사를 통해 도매 할인이 가능합니다. 리셀러 및 대량 구매 프로그램.
보안 모범 사례
강력한 보안에는 단순히 m을 구현하는 것 이상이 필요합니다.TLS:
- 인증서가 정기적으로 업데이트되도록 자동화된 인증서 회전을 구현합니다.
- 손상된 인증서를 빠르게 무효화하기 위해 인증서 폐지 목록을 유지 관리합니다.
- RSA 키의 경우 최소 2048비트의 강력한 키 크기를 사용하세요.
- 보안만 허용하도록 서버를 구성하세요. TLS 버전 및 강력한 암호 제품군
클라이언트 보안 전략에는 강력한 액세스 제어를 통해 개인 키를 보호하는 것이 포함되어야 합니다. 정기적인 보안 감사는 시간이 지남에 따라 시스템의 무결성을 유지하는 데 도움이 됩니다.
일반적인 문제 해결
인증서 체인 문제
m을 구현할 때TLS, 인증서 체인 문제가 발생할 수 있습니다. 이는 일반적으로 다음에서 비롯됩니다.
- 불완전한 인증서 체인
- 부적절하게 설치된 중간 인증서
이러한 문제를 해결하려면:
- 신뢰 앵커 구성이 올바른지 확인하세요
- 필요한 모든 인증서가 있는지 확인하세요
연결 문제
연결 문제는 종종 다음과 관련이 있습니다.
- 방화벽 설정 차단 TLS 교통
- 잘못된 인증서 권한
문제를 해결하려면 :
- 인증서 이름이 올바르게 지정되었는지 확인하세요.
- 의도된 용도에 맞는지 확인하십시오.
성능 고려 사항
성능 고려 사항은 규모에 따라 중요해집니다. 성능을 최적화하려면:
- 반복되는 핸드셰이크의 오버헤드를 줄이기 위해 세션 캐싱을 구현합니다.
- 보안과 성능의 균형을 이루는 효율적인 암호 제품군을 선택하세요
- 불필요한 오버헤드가 발생하지 않도록 인증서 검증 프로세스를 모니터링합니다.
결론
