[CS기술면접] 보안 및 인증

bbbbbhyun·2026년 5월 1일

Study

목록 보기
27/28

암호화 기술

  • 대칭키 암호화
    • 암호화와 복호화에 동일한 키 사용
    • 대표 알고리즘
      • AES: 가장 널리 사용, 128/192/256비트 지원 (숫자 클수록 보안↑, 속도↓)
      • DES: 키 길이 짧아 사용 안 함
    • 장점
      • 빠른 성능: 알고리즘 단순, 계산 비용 낮음
      • 대용량 데이터 실시간 암호화 가능
    • 단점
      • 키 배송 문제: 양쪽이 같은 키를 미리 안전하게 공유해야 함
      • 키 관리 문제: N명 통신 시 N(N-1)/2개 키 필요 (10명=45개, 100명=4,950개)
  • 비대칭키 암호화
    • 공개키 + 개인키 한 쌍의 서로 다른 키 사용, 수학적으로 연결되어 있지만 하나로 다른 하나 계산 불가능
    • 대표 알고리즘
      • RSA: 큰 소수 곱셈은 쉽지만 인수분해는 어려운 수학 성질 이용 (SSL/TLS, SSH)
      • ECC: 타원곡선 암호화
    • 키 구성
      • 공개키: 누구에게나 공개 가능, 누군가 나에게 메시지 보낼 때 암호화/ 디지털 서명 검증
      • 개인키: 절대 외부 노출 금지, 공개키로 암호화된 메시지 복호화 / 디지털 서명 생성
    • 장점
      • 키 배송 문제 해결: 공개키는 안전하게 공유 가능
      • 키 관리 용이: N명에 N쌍만 필요 (대칭키의 N(N-1)/2개보다 훨씬 적음)
      • 디지털 서명: 송신자 인증 + 메시지 무결성 보장
    • 단점
      • 느린 속도: 대칭키 대비 느림, 대용량 데이터 부적합
      • 큰 키 크기: 같은 보안 수준에서 대칭키 256비트 vs RSA 2048비트 (저장공간/대역폭더 필요)
  • SSL/TLS 네트워크 통신 암호화 프로토콜
    • SSL: 초기 버전

    • TLS: SSL의 표준화된 후속 버전 (관습적으로 SSL 또는 SSL/TLS로 통칭)

      주요 기능

    1. 암호화: 통신 내용 보호, 도청 방지

    2. 무결성 보장: 데이터 중간 변조 방지 (해시 함수 + MAC)

    3. 인증: 통신 상대방 신원 확인 (주로 서버, 클라이언트 인증도 가능)

      위치 및 활용

    • OSI 모델: 전송 계층과 응용 계층 사이
    • HTTP + TLS = HTTPS
    • SMTP + TLS = SMTPS
    • FTP, IMAP 등 다양한 프로토콜에 적용 가능

통신 보안

  • CORS(Cross-Origin Resource Sharing)
    • 웹 브라우저가 보안상 다른 도메인(출처)의 서버로 리소스를 요청할 때, 서버가 이를 허용하거나 거부하는 HTTP 헤더 기반의 보안 메커니즘

인증 매커니즘

  • Cookie
    • 브라우저에 저장되는 상태값이며, 인증 정보를 실어나르는 수단입니다.
    • 핵심: 서버가 클라이언트에 데이터를 저장하고, 클라이언트는 매 요청마다 이를 헤더에 포함해 보냅니다.
    • 보안 대응: 자바스크립트로 접근 가능한 XSS 공격을 막기 위해 HttpOnly 설정을, 네트워크 탈취를 막기 위해 HTTPS 환경에서만 전송되는 Secure 설정을 반드시 병행해야 합니다.
    • 면접 팁: 쿠키는 인증 방식이라기보다, 세션 ID나 JWT를 저장하고 전달하기 위한 물리적인 매개체로 정의하고 있습니다.
  • session
    • 서버가 상태를 관리하는(Stateful) 방식이며, 높은 제어권이 장점입니다.
    • 작동: 서버 메모리나 DB에 사용자 정보를 저장하고 클라이언트에겐 Session ID만 발급합니다.
    • 장점: 서버가 세션의 유효성을 완전히 통제합니다. 계정 탈취 의심 시 서버에서 즉시 세션을 파기(Force Logout)할 수 있습니다.
    • 단점(확장성 이슈): 서버가 여러 대인 분산 환경(Scale-out)에서는 세션 불일치 문제가 발생합니다. 이를 해결하기 위해 Sticky Session을 설정하거나 Redis 같은 별도 세션 저장소를 운영해야 하므로 인프라 복잡도와 비용이 증가합니다.
    • 실무 연결: 기존 모놀리식 레거시 어드민에서는 이 방식을 사용했으나, 시스템 확장 시 서버 자원 점유율이 높아지는 한계가 있었습니다.
  • JWT (JSON Web Token)
    • 서버의 상태 저장이 필요 없는(Stateless) 방식이며, 확장성이 매우 뛰어납니다.
    • 작동: 인증에 필요한 데이터를 토큰 자체에 암호화(Signature)하여 담습니다. 서버는 토큰의 유효성만 검증할 뿐 별도의 상태를 저장하지 않습니다.
    • 장점: 서버가 비대해져도 세션 동기화 과정이 필요 없어 수평적 확장(Horizontal Scaling)에 매우 유리합니다. 또한 마이크로서비스(MSA)나 모바일 앱 환경에서도 표준화된 방식으로 연동이 쉽습니다.
    • 단점: 한 번 발급된 토큰은 유효기간 만료 전까지 서버에서 강제 제어가 어렵습니다. 이를 보완하기 위해 짧은 주기의 Access Token과 긴 주기의 Refresh Token을 함께 운용합니다.

브라우저 저장소

  • cookie storage
    • 클라이언트 저장소지만, 모든 HTTP 요청(Request)마다 헤더에 실려 서버로 전송
    • 따라서 불필요한 데이터를 많이 넣으면 트래픽 낭비가 심합니다. 대신 HttpOnly 설정을 통해 자바스크립트 접근을 막을 수 있어 보안상 유리
  • local storage
    • 지워지면 안 되는 사용자 설정 & 반영구적 데이터
  • Session Storage
    • 휘발되어도 상관없는 임시 데이터 & 탭별 독립 데이터

      구분CookieLocal StorageSession Storage
      수명만료 기한 설정 가능영구적(지우기 전까지)탭/브라우저 닫으면 삭제
      서버 전송자동 전송전송 안 함전송 안 함
      용량작음(4KB)큼(5MB~)큼(5MB~)
      접근 범위모든 탭/창 공유모든 탭/창 공유해당 탭 안에서만
      주 용도보안(인증), 서버 통신개인화 설정, 영구 캐시임시 상태, 폼 데이터
profile
BackEnd developer

0개의 댓글