728x90
반응형

인증과 인가의 기본 개념

  • 인증(Authentication): 사용자의 신원을 확인하는 과정 (놀이공원 입장권)
  • 인가(Authorization): 인증된 사용자에게 특정 리소스에 대한 접근 권한을 부여하는 과정 (놀이공원에서만 사용가능)

 

인증 방법의 발전

3.1. 기본 인증

- 사용자 ID와 비밀번호를 직접 입력

- 보안상 취약점 존재

 

3.2. 쿠키/세션 기반 인증

- 브라우저의 쿠키를 이용한 사용자 정보 저장 (클라이언트 저장)

- 서버 측 세션 관리의 도입 (서버 저장)

 

3.3. 토큰 기반 인증

- JWT(JSON Web Token) 활용

- 무상태성(Stateless) 구현으로 서버 부하 감소

- 토큰 기반 인증의 구체적 구현

 

4.1. 액세스 토큰과 리프레시 토큰

- 액세스 토큰: 짧은 유효기간, 실제 인증에 사용

- 리프레시 토큰: 긴 유효기간, 액세스 토큰 갱신에 사용

 

4.2. 토큰 기반 인증의 장단점

장점: 서버 확장성 개선, DB 조회 최소화

단점: 토큰 탈취 시 보안 위험

 

보안 강화 방법

- HTTPS 사용

- HttpOnly 옵션 활용

- 토큰 만료 시간 조절

 

기타 고려사항

- OAuth를 통한 외부 서비스 인증

- 인증 서버 분리

- SSL/TLS 활용

 

결론

인증과 인가 구현보안과 사용자 편의성 사이의 균형을 맞추는 과정입니다. 서비스의 특성과 요구사항에 맞는 최적의 방식을 선택하는 것이 중요합니다.

728x90
반응형
728x90
반응형

1. HTTP vs HTTPS

웹 통신의 기본 프로토콜인 HTTP(Hypertext Transfer Protocol)는 클라이언트와 서버 간의 데이터 교환을 위한 기본적인 규칙을 제공합니다. 그러나 HTTP는 보안 측면에서 몇 가지 중요한 취약점을 가지고 있습니다. 이러한 취약점을 해결하기 위해 개발된 것이 바로 HTTPS(HTTP Secure)입니다.

HTTPS는 기존 HTTP 프로토콜에 보안 계층을 추가한 것으로, 주로 SSL(Secure Sockets Layer) 또는 그 후속 버전인 TLS(Transport Layer Security)를 사용합니다. 이를 통해 데이터의 기밀성, 완전성, 그리고 통신 상대방 인증 측면에서 큰 개선을 이루었습니다.

2. HTTP의 보안 취약점

HTTP가 가진 주요 보안 취약점은 다음과 같습니다:

a) 암호화 기능 부재:
   HTTP는 데이터를 평문으로 전송합니다. 이는 누구나 네트워크 트래픽을 감시하면 통신 내용을 쉽게 볼 수 있다는 것을 의미합니다. 예를 들어, 공공 Wi-Fi에서 HTTP를 사용하면 비밀번호나 신용카드 정보 같은 민감한 데이터가 노출될 위험이 있습니다.

b) 메시지 변경 감지 불가
   HTTP는 전송 중 데이터가 변경되었는지 확인할 방법이 없습니다. 즉, 중간자 공격(man-in-the-middle attack)에 취약합니다. 악의적인 제3자가 통신을 가로채 내용을 변경해도 수신자는 이를 알아차리기 어렵습니다.

c) 통신 상대 인증 불가
   HTTP는 통신 상대방이 진짜 의도한 서버나 클라이언트인지 확인할 수 없습니다. 이는 피싱 사이트 같은 위장 서버나 악의적인 클라이언트의 요청을 구분하기 어렵다는 것을 의미합니다.

3. HTTPS의 구조
HTTPS는 이러한 HTTP의 취약점을 해결하기 위해 HTTP와 TCP 사이에 보안 계층을 추가합니다. 이 보안 계층은 SSL/TLS 프로토콜을 사용합니다.

SSL과 TLS는 본질적으로 같은 프로토콜의 다른 버전입니다. TLS가 SSL의 더 최신 버전이지만,

일반적으로 'SSL'이라는 용어가 더 널리 사용됩니다. 이 프로토콜은 다음과 같은 보안 기능을 제공합니다
- 데이터 암호화
- 데이터 무결성 검증
- 서버 (그리고 선택적으로 클라이언트) 인증

4. 암호화 방식: 대칭키와 비대칭키
HTTPS는 두 가지 주요 암호화 방식을 사용합니다:


a) 대칭키 암호화:
   - 동일한 키를 사용하여 암호화와 복호화를 수행합니다.
   - 장점: 암호화와 복호화 속도가 빠릅니다.
   - 단점: 키를 안전하게 공유하는 것이 어렵습니다. 처음에 키를 전달할 때 탈취 당하면 모든 통신이 위험해집니다.

b) 비대칭키 암호화 (공개키 암호화)
   - 두 개의 다른 키(공개키와 개인키)를 사용합니다.
   - 공개키로 암호화한 데이터는 개인키로만 복호화할 수 있습니다.
   - 장점: 키 교환의 안전성이 높습니다.
   - 단점: 대칭키 방식에 비해 암호화/복호화 속도가 느립니다.

HTTPS는 이 두 방식의 장점을 활용하기 위해 하이브리드 방식을 사용합니다
1. 처음에 비대칭키 암호화를 사용하여 안전하게 대칭키를 교환합니다.
2. 이후 실제 데이터 통신은 빠른 대칭키 암호화를 사용합니다.

5. 인증서와 CA(Certificate Authority)
HTTPS에서 중요한 또 다른 요소는 디지털 인증서입니다. 인증서는 서버의 신원을 보증하는 역할을 합니다. 이 인증서는 신뢰할 수 있는 제3자 기관인 CA(Certificate Authority)에서 발급합니다.

CA의 역할:
- 서버의 신원을 확인합니다.
- 서버의 공개키를 포함한 인증서를 발급합니다.
- 인증서에 디지털 서명을 추가하여 인증서의 진위를 보증합니다.

클라이언트(예: 웹 브라우저)는 서버가 제시한 인증서를 CA의 공개키를 사용하여 검증합니다. 이를 통해 서버의 신원과 공개키의 신뢰성을 확인할 수 있습니다.

6. HTTPS 통신의 흐름
HTTPS 통신은 다음과 같은 단계로 이루어집니다
1) 클라이언트가 서버에 연결을 요청합니다.
2) 서버는 자신의 SSL 인증서를 클라이언트에게 전송합니다.
3) 클라이언트는 받은 인증서를 확인합니다:
   - 인증서가 신뢰할 수 있는 CA에 의해 발급되었는지 확인
   - 인증서가 유효한지 (만료되지 않았는지) 확인
   - 인증서의 도메인 이름이 접속하려는 웹사이트와 일치하는지 확인
4) 인증서가 유효하다고 판단되면, 클라이언트는 대칭키(세션 키)를 생성합니다.
5) 클라이언트는 이 세션 키를 서버의 공개키로 암호화하여 서버에 전송합니다.
6) 서버는 자신의 개인키를 사용하여 암호화된 세션 키를 복호화합니다.
7) 이제 클라이언트와 서버는 동일한 세션 키를 공유하게 되었고, 이를 사용하여 안전한 대칭키 암호화 통신을 시작합니다.

7. 결론
HTTPS는 SSL/TLS를 통해 HTTP의 보안 취약점을 효과적으로 보완합니다. 대칭키와 비대칭키 암호화의 장점을 결합하고, CA의 인증 시스템을 활용하여 안전한 통신 환경을 제공합니다. 이를 통해 데이터의 기밀성(암호화), 무결성(변조 방지), 그리고 통신 상대방의 신원(인증)을 보장할 수 있습니다.

HTTPS의 사용은 온라인 뱅킹, 전자상거래, 개인정보 처리 등 민감한 정보를 다루는 웹사이트에서 특히 중요하며, 현대 웹의 필수적인 요소로 자리잡았습니다. 사용자의 개인정보 보호와 안전한 온라인 경험을 위해 HTTPS의 중요성은 계속해서 증가하고 있습니다.

728x90
반응형

+ Recent posts