[강의] 정보 보안(Information Security) 개요

Jerry·2025년 11월 10일

코드잇 스프린트 Spring Backend 5기

목록 보기

54/60

정보 보안(Information Security) 개요

정보보안의 정의와 목적

정보보안은 정보의 기밀성, 무결성, 가용성을 유지하여 불법적인 접근, 변경, 파괴로부터 보호하는 활동이다.
디지털 환경에서 발생하는 사이버 위협과 내부 유출을 방지하기 위해 필수적인 관리·기술적 대책을 포함한다.
조직의 신뢰성 확보와 업무 연속성 유지를 위해 반드시 필요한 핵심 보안 체계이다.

보안 3요소(CIA: 기밀성, 무결성, 가용성)

보안 3요소(CIA)는 정보보호의 핵심 원칙으로, 정보의 보호 수준을 평가하는 기본 개념이다.
기밀성, 무결성, 가용성의 균형 유지가 정보보안의 목표이다.

기밀성(Confidentiality): 인가되지 않은 사용자나 시스템이 정보에 접근하지 못하도록 보호
무결성(Integrity): 정보가 인가되지 않은 방식으로 변경· 훼손되지 않도록 보장
가용성(Availability): 인가된 사용자가 필요한 시점에 정보와 자원에 접근할 수 있도록 유지

위협, 취약접, 공격 개념

위협(Threat): 정보자산에 손상을 가할 가능성이 있는 잠재적 위험 요인
취약점(Vulnerability): 위협이 실제 공격으로 이어질 수 있게 만드는 시스템의 약점이나 결함
공격(Attack): 취약점을 이용하여 정보자산의 기밀성· 무결성· 가용성을 침해하려는 행위

OWASP TOP10 2025 (웹 관련 보안 취약점 상위 10개)

https://owasp.org/

보완 관련 규제

보안 관련 규제는 정보자산을 보호하기 위해 법률로 마련된 강제적 준수 기준과 관리체계를 의미한다.
법적 효력으로 인해 위반 시 행정처분· 과징금· 형사처벌 등의 기업 리스크가 발생하며, 신뢰도 하락 및 운영 및 영업 정지로 이어지며, 기업 입장에서는 실질적인 금전적 손해가 발생 할 수도 있다.

구분	주요 법령·제도	주관 기관	주요 내용
개인정보 보호	개인정보 보호법	개인정보보호위원회(PIPC)	개인정보의 수집·이용·제공·파기에 관한 기본 원칙과 보호조치 의무 규정
정보통신 서비스	정보통신망 이용촉진 및 정보보호 등에 관한 법률(정보통신망법)	과학기술정보통신부	정보통신서비스 제공자의 정보보호, 이용자 개인정보 보호, 침해사고 대응 의무
정보보호 관리체계	ISMS / ISMS-P 인증제도	한국인터넷진흥원(KISA)	기업의 정보보호 관리체계 수립·운영 인증 제도(ISMS) 및 개인정보보호 통합 인증(ISMS-P)
전자금융거래	전자금융거래법	금융위원회, 금융감독원(FSS)	전자금융서비스의 안전성 확보 및 이용자 보호를 위한 기술적·관리적 보호조치 의무
금융보안	금융보안규정(전자금융감독규정 등)	금융감독원(FSS)	금융회사 전산시스템 보안관리, 외부위탁·클라우드 이용 시 보안 점검 의무
의료정보 보호	의료법, 개인정보 보호법(의료정보 포함)	보건복지부	의료기관의 진료정보 보호, 환자 동의 기반의 정보 제공 및 의료데이터 활용 규제
의료데이터 활용	보건의료 데이터 활용 가이드라인	보건복지부	비식별화·가명처리된 의료데이터의 연구·AI 활용 시 보안 요구사항 명시
정보통신 사업자 보안	전기통신사업법	과학기술정보통신부	통신사업자의 통신망 보호, 이용자 개인정보 보호 및 통신비밀 보장 의무
통신보안	통신비밀보호법	방송통신위원회	통신내용·통신사실 정보의 보호 및 불법 도청·감청 방지 규정

보안 관련 대응 기법

구분	주요 기법	설명
기술적 보안	시큐어 코딩 (Secure Coding)	입력값 검증, 예외 처리, 암호화 적용 등을 통해 개발 단계에서 취약점 제거
	암호화 (Encryption)	데이터 전송·저장 시 기밀성 보장 (대칭키, 비대칭키, 해시, 전자서명 등 활용)
	접근통제 (Access Control)	사용자 인증(Authentication) 및 인가(Authorization)를 통한 자원 접근 제한
	침입탐지/차단 (IDS/IPS)	네트워크 및 시스템의 비정상 행위를 탐지하고 공격을 실시간 차단
	패치 관리 (Patch Management)	취약점 발견 시 즉각적인 보안 패치 및 업데이트 수행
	백업 및 복구 (Backup & Recovery)	장애·침해 사고 발생 시 데이터를 복원하고 업무 연속성 확보
관리적 보안	보안 정책 수립 (Security Policy)	보안 목표·원칙·운영지침을 문서화하여 전사적 기준 수립
	보안 교육 및 인식 제고 (Security Awareness)	임직원 대상 보안 인식 교육, 피싱 훈련 등을 통한 내부 보안 강화
	위험관리 (Risk Management)	자산, 위협, 취약점 분석을 통한 리스크 식별 및 대응 우선순위 설정
	감사 및 모니터링 (Audit & Monitoring)	시스템 접근기록, 로그, 변경 이력 점검으로 이상 징후 탐지
	보안 인증제도 (ISMS, ISO27001)	보안 관리체계 인증을 통해 관리적 통제 수준 검증
물리적 보안	출입통제 (Access Control System)	서버실·데이터센터 출입을 제한하고 권한자만 접근 허용
	CCTV 및 보안경비	주요 구역 실시간 감시 및 침입 탐지
	재해복구센터 (DR Center)	자연재해나 장애 시 서비스 연속성 확보 위한 대체 인프라
통합 보안 운영 (DevSecOps)	DevSecOps 기반 자동화 보안	개발 파이프라인에 보안검증 자동화 도구(SAST/DAST) 통합
	코드 검증 및 취약점 스캐닝	SonarQube, OWASP ZAP 등으로 코드 품질·보안 점검
	API 보안 및 인증 관리	OAuth 2.0, JWT, API Gateway를 이용한 안전한 서비스 연동

KISA 가이드

KISA는 우리나라 정보보안·개인정보보호의 실질적 컨트롤타워로, 법적 규제 이행뿐 아니라 산업 현장에서 보안 정책·기술적 기준을 표준화하고 안내하는 역할을 수행한다.

ISMS-P: 정보보호·개인정보보호 관리 체계 인증 기준
시큐어 코딩: 개발단계 보안 취약점 예방 원칙
비식별 조치: 개인정보 가명·비식별 처리 기준

기술적 보안 조치 - 소프트웨어 개발 보안 가이드

KISA의 「소프트웨어 개발 보안 가이드」는 소프트웨어 개발 전 과정에서 발생 가능한 보안 취약점을 예방하기 위한 체계적 지침이다. 기획·설계·구현·테스트 단계별로 안전한 개발 절차와 시큐어코딩 원칙을 제시한다.
안전한 SW 품질 확보와 보안 내재화를 통해 침해사고를 사전에 차단하는 것을 목표로 한다.

유저 관리 기능

유저 기능의 이해와 인증 개념

유저 기능의 개념

유저 기능은 웹 서비스에서 사용자를 식별하고 개별화된 데이터를 관리하기 위한 핵심 기능이다.
이를 통해 사용자별 데이터 보호와 개인화된 서비스 제공, 권한 제어가 가능하다. 대부분의 현대 웹 서비스는 이러한 유저 기능을 기반으로 인증과 인가를 수행하며, 사용자에게 맞춤형 경험을 제공한다.

유저 기능의 필요성과 홀용

웹 서비스에서 유저 기능의 역할

구분	역할	내용
데이터 보호	사용자별 데이터 격리 및 보안 강화	각 사용자의 데이터를 분리하여 다른 사용자가 접근하지 못하도록 보호
개인화 서비스 제공	맞춤형 콘텐츠 및 설정 제공	사용자 선호도, 이용 이력에 따라 개인화된 화면 및 추천 기능 제공
서비스 품질 향상	사용자 행동 분석 및 피드백 반영	로그 분석과 이용 패턴을 통해 서비스 개선 및 기능 고도화
수익 모델 구현	결제·구독 등 상업적 기능 지원	사용자 계정 기반으로 결제, 포인트, 구독 등 유료 서비스 제공
권한 관리	사용자 역할별 접근 제어	일반 사용자, 관리자 등 권한에 따라 기능 접근을 제한
사용자 경험 향상	로그인 유지, 맞춤 인터페이스 제공	개별 사용자 중심의 UX 설계로 서비스 만족도 향상

유저 식별을 통한 맞춤형 서비스

유저 식별을 통한 맞춤형 서비스는 사용자의 고유 정보를 기반으로 개인의 선호도, 이용 이력, 권한 등을 분석하여 각 사용자에게 최적화된 콘텐츠와 기능을 제공하는 서비스 방식이다.

핵심 요소
1. 개인 데이터 관리: 프로필, 설정, 이용 기록 등 사용자별 데이터 저장 및 활용
2. 권한 기반 접근 제어: 사용자 역할에 따른 기능 제한 및 접근 권한 설정
3. 개인화 알고리즘: 이용 패턴과 선호도를 분석하여 맞춤형 콘텐츠와 추천 제공

유저 기능이 필요한 서비스 사례 분석

서비스 유형	유저 기능	적용 내용	주요 역할
소셜 미디어 플랫폼	개인 타임라인, 게시물 및 친구/팔로워 관리	사용자 관계 관리 및 개인화된 소셜 경험 제공	개인화된 피드와 관계 기반 콘텐츠 제공
전자상거래 사이트	장바구니, 주문·결제 정보, 배송지 관리	개인별 구매 이력 저장 및 맞춤형 상품 추천	맞춤형 상품 추천 및 구매 경험 향상
온라인 학습 플랫폼	학습 진도, 성취도, 강의 접근 권한 관리	사용자별 학습 진행 상황 추적 및 개인화된 학습 제공	학습 효율 향상 및 맞춤형 교육 제공
협업 도구 (프로젝트 관리 등)	팀 구성원 관리, 역할·권한 설정, 개인 작업 현황 추적	역할 기반 접근 제어와 효율적인 협업 지원	권한 관리와 협업 생산성 극대화

인증(Authentication)의 개념

인증의 정의와 목적

인증(Authentication)은 사용자가 주장하는 신원이 실제로 맞는지 확인하는 절차이다.
사용자가 주장하는 ID가 실제 본인임을 확인하기 위해 비밀번호, 토큰, 생체정보 등 검증 수단을 사용한다.
목적은 비인가자의 접근을 방지하고, 서비스의 기밀성과 무결성을 보장하는 것이다.

유저 모델과 인증 정보 관리

유저 모델은 사용자의 식별 정보와 권한, 인증 관련 속성을 저장하는 구조로 사용된다.
인증 정보는 비밀번호나 토큰 등 사용자의 자격 증명을 안전하게 관리하고 검증하는 데 활용된다.
시스템은 이를 통해 사용자의 신원을 확인하고 세션이나 토큰을 발급하여 접근을 제어한다.

이메일과 비밀번호 기반 인증 방식

이메일과 비밀번호 기반 인증 방식은 사용자가 등록된 이메일 주소와 비밀번호를 입력하여 본인임을 증명하는 가장 기본적인 로그인 방법이다. 서버는 입력된 이메일을 통해 사용자를 조회하고, 저장된 해시 비밀번호와 비교하여 일치 여부를 확인한다. 인증이 성공하면 세션이나 토큰을 발급하여 이후 요청에서 사용자의 권한을 유지한다.

인증 워크플로우의 이해

회원가입 워크플로우

회원가입 워크플로우는 사용자가 새로운 계정을 생성하는 과정으로, 기본 흐름은 다음과 같다.

사용자가 회원가입 폼에 이메일, 비밀번호 등 정보를 입력한다.
서버는 입력 정보를 검증하고, 중복 계정 여부를 확인한다.
검증 완료 후 사용자 정보를 데이터베이스에 저장하고, 가입 완료 또는 인증 메일을 전송한다.

로그인 워크플로우

로그인 워크플로우는 사용자가 등록된 계정으로 인증을 수행하는 과정으로 기본 흐름은 다음과 같다.

사용자가 ID와 비밀번호를 입력하여 서버로 전송한다.
서버는 데이터베이스의 사용자 정보와 비교하여 일치 여부를 확인한다.
인증이 성공하면 세션이나 토큰을 발급하여 서비스 접근 권한을 부여한다.

인증 상태 유지의 필요성

인증 상태 유지는 사용자가 로그인할 때마다 매번 인증 절차를 반복하지 않도록 하기 위한 것이다.
로그인 이후에도 사용자의 신원을 지속적으로 확인하여 서비스 이용의 편의성과 보안을 동시에 보장한다.
이를 통해 세션이나 토큰을 기반으로 인증 정보를 유지하며, 불필요한 재인증을 방지한다.

쿠키와 세션 기반 인증

HTTP와 Stateless의 개념

HTTP의 Stateless는 각 요청이 독립적으로 처리되어 이전 요청의 상태를 기억하지 않는 특성을 의미한다.
서버는 클라이언트의 과거 요청 정보를 저장하지 않으며, 매 요청마다 필요한 모든 정보를 함께 전송해야 한다. 이로 인해 확장성과 단순성이 높지만, 로그인 유지 같은 상태관리가 어렵다.

쿠키의 개념과 특성

쿠키의 정의

쿠키(Cookie)는 웹 서버가 사용자의 브라우저에 저장하는 작은 데이터 조각으로, 사용자 식별이나 로그인 상태 유지 등을 위해 사용된다. HTTP 프로토콜은 비연결성(stateless) 이므로, 쿠키를 통해 사용자의 상태 정보를 유지하며 요청 간 연속성을 제공한다.
즉, 쿠키는 HTTP 통신 과정에서 클라이언트와 서버 간 상태를 보존하기 위한 핵심 메커니즘이다.

쿠키의 구조

쿠키의 구조는 이름(Name)과 값(Value) 쌍으로 이루어진 데이터 형태다.
옵션 속성으로 유효 기간(Max-Age/Expires), 경로(Path), 도메인(Domain), 보안 옵션(Secure, HttpOnly) 등을 포함한다. HTTP 요청 시 ‘Cookie’ 헤더에 포함되어 서버로 전송된다.

브라우저에서의 쿠키 처리 방식

브라우저에서의 쿠키 처리 방식은 다음과 같다.

서버가 Set-Cookie 헤더를 통해 쿠키를 클라이언트(브라우저)에 전달한다.
브라우저는 받은 쿠키를 로컬 저장소에 저장하고, 유효 기간 및 도메인 정보를 관리한다.
이후 동일한 도메인으로 요청 시 브라우저는 자동으로 Cookie 헤더에 해당 쿠키를 포함시켜 서버로 전송한다.

쿠키의 생명주기(Life Cycle)

쿠키의 생명주기와 범위는 쿠키가 언제까지, 어떤 영역에서 유효한지를 결정하는 요소이다.
쿠키는 서버가 클라이언트에 저장하는 데이터로, 만료 시간과 도메인 설정에 따라 자동으로 유지되거나 삭제되며, 유지되는 경우 같은 서버의 전송하는 경우 기존 cookie를 담아 request로 전달한다.

단계	설명
서버 생성 (Set-Cookie)	서버가 `Set-Cookie` 응답을 통해 쿠키를 생성하고 `Max-Age`, `Expires`, `Domain`, `Path`, `Secure`, `HttpOnly`, `SameSite` 등 속성을 설정합니다
클라이언트 수신	브라우저가 응답의 `Set-Cookie`를 수신하여 로컬 저장소(쿠키 저장소)에 저장합니다
브라우저 종료	세션 쿠키는 브라우저 종료 시 삭제되고, `Max-Age`/`Expires`가 설정된 영속(퍼시스턴트) 쿠키는 유지됩니다
브라우저 로드	브라우저 재시작 시 영속 쿠키는 복원되어 유지됩니다
URL 접근 요청	클라이언트가 특정 URL에 요청할 때 요청 도메인과 경로, 스킴(HTTP/HTTPS) 등을 기준으로 해당 도메인·경로에 유효한 쿠키를 확인합니다
쿠키 로드	도메인·경로·보안(예: Secure, SameSite) 조건을 만족하는 쿠키를 저장소에서 불러옵니다
서버 전송	브라우저가 선택된 쿠키를 `Cookie` 요청 헤더에 포함하여 서버로 전송합니다

쿠키의 범위 (Scope)

쿠키의 생명주기와 범위는 쿠키가 언제까지, 어떤 영역에서 유효한지를 결정하는 요소이다.
쿠키는 서버가 클라이언트에 저장하는 데이터로, 만료 시간과 도메인 설정에 따라 유지되거나 삭제된다.

구분	설명	예시
Domain	쿠키가 전송될 수 있는 도메인을 지정하며, 서브도메인 포함 여부를 결정합니다	`Domain=.example.com` → `www.example.com`, `shop.example.com` 모두 적용
Path	쿠키가 유효한 URL 경로를 지정하여 특정 디렉토리 내에서만 사용 가능하게 합니다	`Path=/user` → `/user/profile`, `/user/settings`에서만 전송
Secure	HTTPS 환경에서만 쿠키를 전송하도록 제한하여 네트워크 구간에서의 탈취를 방지합니다	`Secure` → 암호화된 HTTPS 요청에만 전송
HttpOnly	JavaScript에서 쿠키 접근을 차단하여 XSS 공격으로부터 보호합니다	`HttpOnly` → 클라이언트 스크립트로 접근 불가, 서버 전송만 허용

세션 기반 인증의 이해

세션의 개념과 특징

세션(Session)은 클라이언트와 서버 간의 연결 상태를 일정 시간 동안 유지하기 위한 서버 측 저장 기술이다.
쿠키가 클라이언트에 저장되는 반면, 세션은 서버에 저장되어 보안성이 높다. 세션의 특징은 아래와 같다.

서버 저장 방식: 사용자 정보를 서버에 저장하고, 클라이언트에는 세션 ID만 쿠키로 전달
상태 유지: 로그인 등 지속적인 연결 상태를 유지할 수 있음
유효 시간 설정: 일정 시간 활동이 없으면 세션이 자동으로 만료됨
보안성 높음: 클라이언트에 데이터가 직접 저장되지 않아 변조 위험이 낮음
쿠키 활용: 세션 ID를 쿠키에 저장하여 서버와 클라이언트를 연결함

서버 측 세션 저장소 관리

서버 측 세션 저장소 관리는 사용자의 로그인 상태 등 세션 데이터를 서버 메모리(HttpSession)에 저장해 관리하는 방식이다. Spring에서는 기본적으로 메모리에 저장되며, 서버 재시작 시 세션이 초기화된다.
다중 서버나 세션 공유가 필요한 환경에서는 Spring Session과 Redis를 연동하여 분산 세션 저장이 가능하다.

세션 ID를 통한 사용자 식별

세션 ID(Session ID)는 사용자를 구분하기 위해 서버가 부여하는 고유한 식별자이다.
클라이언트는 쿠키 등에 저장된 세션 ID를 요청 시 함께 전송한다. 서버는 해당 ID를 통해 사용자의 세션 데이터를 찾아 인증 상태나 사용자 정보를 식별한다.

쿠키와 세션 비교

구분	쿠키 (Cookie)	세션 (Session)
저장 위치	클라이언트(브라우저)	서버
저장 형태	브라우저에 텍스트 형태로 저장	서버 메모리 또는 저장소(DB, Redis 등)에 저장
보안성	낮음 (조작·탈취 위험, 암호화 필요)	높음 (데이터를 서버에서 관리, 클라이언트에는 세션 ID만 저장)
유지 방식	`Expires`, `Max-Age`에 따른 만료 시간 기반	일정 시간 비활동 시 자동 만료 (Session Timeout)
식별 방식	쿠키 자체에 데이터 포함	세션 ID를 통해 서버의 세션 데이터 참조
사용 목적	사용자 편의 설정 (자동 로그인, 테마, 장바구니 등)	로그인 상태 유지, 인증 및 권한 관리
서버 부하	낮음 (클라이언트가 데이터 관리)	높음 (서버 리소스 사용)
전송 방식	HTTP 요청 시 자동 전송 (`Cookie` 헤더 사용)	세션 ID를 쿠키에 저장하고 이를 통해 서버에서 세션 관리
보안 설정	`Secure`, `HttpOnly`, `SameSite` 등 옵션으로 보호 가능	HTTPS, 세션 타임아웃, 세션 무효화 등으로 탈취 방지

쿠키와 세션을 활용한 인증 구현

서버는 사용자가 로그인에 성공하면 Set-Cookie 헤더를 통해 세션 ID를 클라이언트로 전달한다.
브라우저는 이 세션 ID를 쿠키에 저장하고, 이후 요청 시 자동으로 Cookie 헤더에 포함시켜

클라이언트(브라우저)는 서버로부터 전달받은 세션 ID를 쿠키에 저장한다.
이후 동일한 도메인으로 요청할 때마다 브라우저는 자동으로 Cookie 헤더에 세션 ID를 포함해 전송한다.
서버는 요청 헤더의 세션 ID를 확인하여 해당 사용자의 세션 정보를 조회한다.
이를 통해 사용자의 로그인 상태나 인증 정보를 지속적으로 유지할 수 있다.

세션 생성 및 관리 방법

세션은 사용자가 로그인 등 특정 요청을 보낼 때 서버에서 생성된다. 서버는 고유한 세션 ID를 발급하고 이를 클라이언트에 쿠키로 전달한다. 이후 요청마다 세션 ID를 이용해 사용자의 상태를 추적하고 세션을 관리한다.

로그아웃 구현과 세션 무효화

로그아웃은 사용자의 인증 정보를 제거하여 세션을 종료하는 과정이다.
서버는 해당 사용자의 세션을 무효화(invalidate)하여 더 이상 접근할 수 없게 한다.
클라이언트 측에서는 저장된 세션 쿠키를 삭제하여 인증 상태를 완전히 종료한다.

쿠키와 세션 보안 설정

Secure와 HttpOnly 설정의 이해와 적용

Secure : HTTPS(암호화된 통신) 환경에서만 쿠키를 전송하도록 제한하는 속성이다.
HttpOnly : JavaScript에서 쿠키 접근을 차단하여 XSS(교차 사이트 스크립팅) 공격을 방지한다.
두 속성을 함께 설정하면 네트워크 노출과 스크립트 기반 공격을 모두 차단해 쿠키 보안성이 크게 향상된다.

SameSite 설정의 이해와 적용

SameSite는 쿠키가 외부 사이트 요청(cross-site request) 에 포함되는 방식을 제어하는 속성이다.
Strict, Lax, None 옵션을 통해 쿠키의 전송 범위를 조정하여 CSRF 공격을 방지한다.
특히 SameSite=None은 제3자 요청 허용 시 반드시 Secure와 함께 사용해야 한다.

CSRF 공격 예방을 위한 설정

CSRF 공격은 사용자의 인증 정보를 도용해 의도치 않은 요청을 수행하게 만드는 공격이다.
Spring Security에서는 CSRF 토큰을 발급하고, 요청 시 이를 검증하여 외부 요청을 차단한다.
또한 SameSite, Referer 검증, POST 요청 제한 등을 함께 적용해 보안을 강화한다.

기본 인증과 인코딩

기본 인증(Basic Authentication)

기본 인증의 개념과 구현 방법

기본 인증은 HTTP 프로토콜에서 사용자 ID와 비밀번호를 Base64로 인코딩하여 Authorization 헤더에 담아 전송하고 서버는 이 정보를 디코딩하여 사용자의 자격 증명을 검증하는 방식이다.
Spring Security에서는 httpBasic() 설정만으로 손쉽게 구현 가능하며, 브라우저 기본 팝업을 통해 인증을 수행한다.
단, 평문 전송 위험이 있어 반드시 HTTPS 환경에서 사용해야 한다.

RFC 7617

RFC 7617은 HTTP Basic Authentication 메커니즘을 정의한 표준 문서다.
사용자의 인증 정보를"username:password" 형태로 결합한 뒤, 이를 Base64로 인코딩하여 Authorization: Basic 헤더에 포함시켜 전송하도록 규정한다.
이 표준은 단순하지만 암호화 기능이 없으므로, 반드시 TLS/HTTPS 환경에서 사용해야 안전하다.

기본 인증의 한계와 보안 위험성

기본 인증은 사용자 아이디와 비밀번호를 Base64로 인코딩하여 전송하기 때문에 보안에 취약하다.
인코딩 된 값은 암호화가 아니므로, 네트워크에서 패킷이 탈취되면 쉽게 복호화 될 수 있다.
또한 토큰 만료나 갱신 기능이 없어 세션 관리가 어렵고, HTTPS를 사용하지 않으면 중간자 공격(Man-in-the-Middle Attack)에 노출될 위험이 크다.
보완 방법: HTTPS(TLS) 기반 통신으로 인증 정보를 암호화하여 전송하는 것이 가장 효과적이다.

구분	설명
평문 전송 위험	아이디와 비밀번호가 Base64로 단순 인코딩되어 전송 중 탈취 시 쉽게 복호화됨
암호화 미지원	기본 인증 자체에 암호화 기능이 없어 HTTPS를 사용하지 않으면 매우 취약함
세션 관리 한계	토큰 만료나 갱신 기능이 없어 장기 인증 유지 시 보안 위험 증가
중간자 공격 위험	네트워크 구간에서 인증 정보를 가로채거나 변조할 수 있는 위험 존재
재사용 공격 가능	동일 자격 증명이 반복 사용되어, 탈취 시 재사용 공격(Replay Attack)에 취약함

인코딩과 Base64URL

인코딩의 개념과 필요성

인코딩(Encoding)은 데이터를 전송하거나 저장하기 위해 특정 형식으로 변환하는 과정이다.
문자, 이미지, 바이너리 데이터를 표준화된 코드(예: UTF-8, Base64)로 표현한다.
이는 통신 중 데이터 손상이나 해석 오류를 방지하고, 시스템 간 호환성을 확보하기 위해 필요하다.

Base64 및 Base64URL 인코딩 이해

Base64 인코딩 : 바이너리 데이터를 ASCII 문자로 변환하여 전송하는 인코딩 방식으로, 이메일, HTTP 인증 등에서 사용된다.
Base64URL 인코딩 : URL에서 사용 불가능한 문자(+, /, =)를 대체하여 웹 전송에 적합하도록 만든 Base64 변형 방식이다.

HTTP 헤더에서의 인코딩 활용

HTTP 헤더에서의 인코딩은 비-ASCII 문자를 안전하게 전송하거나 바이너리/임의 바이트를 텍스트로 표현하기 위한 기법이다. 주요 용도는 문자 인코딩(문서 바이트 → 유니코드 텍스트 매핑) 지정, URL의 예약문자 이스케이프, 인증·토큰의 텍스트화, 그리고 메일·헤더 필드에서의 비-ASCII 표기 등이다.

기본 인증 보안 고려사항

HTTPS (HyperText Transfer Protocol Secure)의 필요성

HTTPS는 HTTP에 SSL/TLS 암호화 계층을 추가하여 보안을 강화한 통신 프로토콜이다.
데이터를 암호화하여 전송함으로써 중간자 공격, 패킷 도청, 변조를 방지한다.
HTTPS의 필요성은 사용자 개인정보 보호, 인증서 기반의 신뢰 확보, 안전한 로그인 및 결제 등 안전한 웹 서비스 제공을 위함이다.

자격 증명 노출 위험성

자격 증명 노출은 사용자의 아이디· 비밀번호 등 인증 정보가 외부에 유출되는 보안 위협이다.
HTTP 평문 전송, 로그 저장, 브라우저 캐시, 피싱 사이트 등을 통해 발생할 수 있다.
이로 인해 공격자는 인증 없이 시스템에 접근할 수 있어 계정 탈취 및 내부 정보 유출로 이어질 수 있다.

Authorization 헤더와 토큰 기반 인증

Authorization 헤더의 개념

Authorization 헤더는 HTTP 요청에서 사용자 인증 정보를 서버로 전달하기 위한 헤더이다.
기본 인증(Basic), 베어러 토큰(Bearer Token), OAuth 등 다양한 인증 방식을 포함할 수 있다.
서버는 이 헤더를 분석하여 사용자의 신원을 확인하고 접근 권한을 결정한다.

Authorization 헤더의 이해

헤더를 통한 인증 정보 전송

헤더를 통한 인증 정보 전송은 HTTP 요청의 Authorization 헤더를 이용해 서버에 자격 증명을 전달하는 방식이다. 예를 들어, Authorization: Basic <Base64인코딩값> 또는 Authorization: Bearer <토큰> 형태로 전송된다. 서버는 이 정보를 검증하여 사용자의 인증 및 접근 권한을 확인한다.

인증 방식 식별자(Basic, Bearer, Digest 등)

인증 방식 식별자는 Authorization 헤더에서 사용되는 인증 유형을 구분하는 키워드이다.
예를 들어 Basic, Bearer, Digest 등이 있으며, 각 방식에 따라 자격 증명 전달 방식이 다르다.
Bearer는 토큰 기반 인증, Digest는 해시 기반 인증, Basic은 단순 인코딩 방식이다.

RFC 6750 (Bearer Token Usage)

RFC 6750은 OAuth 2.0 프로토콜에서 Bearer 토큰의 사용 방식을 정의한 표준 문서다.
클라이언트는 Authorization: Bearer <token> 형식으로 액세스 토큰을 서버에 전송한다.
서버는 해당 토큰을 검증하여 자원 접근 권한을 부여하며, HTTPS 환경에서의 안전한 전송을 권장한다.

토큰 기반 인증의 개념

토큰의 정의와 특징

토큰(Token)은 인증된 사용자의 신원을 식별하거나 접근 권한을 부여하기 위해 발급되는 임시 자격 증명이다.
서버는 로그인 성공 시 토큰을 발급하고, 클라이언트는 이후 요청 시 이를 전송하여 인증을 대신한다.
대표적으로 JWT(Json Web Token), OAuth2 Access Token 등이 사용된다.

구분	내용
Stateless 인증	서버에 세션 정보를 저장하지 않아 확장성·성능이 우수함
유효 기간 존재	토큰에 만료 시간이 포함되어 자동으로 무효화됨
휴대성 높음	클라이언트가 어디서든 토큰만으로 인증 가능
보안 의존성	토큰 탈취 시 악용 가능하므로 HTTPS 사용·만료 관리가 필수
분산 환경 적합	서버 간 세션 공유 없이 인증 가능해 마이크로서비스 구조에 적합
표준 형식 지원	JWT, OAuth2 등 표준화된 형식을 지원하여 다양한 시스템과 연동 용이

세션 기반 인증과의 비교

구분	세션 기반 인증 (Session-based)	토큰 기반 인증 (Token-based)
저장 위치	서버 메모리 또는 저장소(DB, Redis 등)	클라이언트(LocalStorage, Cookie 등)
상태 관리	Stateful (서버가 세션 상태 유지)	Stateless (서버는 상태 비저장)
인증 방식	세션 ID를 쿠키로 전달하여 서버에서 검증	토큰을 `Authorization` 헤더에 담아 서버에서 검증
확장성	서버 간 세션 공유 필요 → 확장 어려움	서버 상태 공유 불필요 → 확장 용이
보안성	세션 하이재킹 위험 존재하지만 서버 관리로 제어 가능	토큰 탈취 시 재사용(Replay) 위험 존재
만료 관리	서버에서 세션 만료 처리	토큰 내부에 유효기간(Expiration) 포함
사용 환경	전통적인 웹 애플리케이션에 적합	REST API, 모바일, 마이크로서비스 환경에 적합
예시	`JSESSIONID` (Spring Session 등)	`JWT`, `OAuth2 Access Token`
결론	확장성은 낮지만 보안성은 강함	확장성은 높지만 보안 관리가 더 중요함

토큰 기반 인증의 워크플로우

토큰 기반 인증은 사용자가 로그인하면 서버가 인증 정보를 검증하고 토큰을 발급하는 방식이다.
클라이언트는 이후 요청마다 토큰을 전송하여 인증을 대체하며, 서버는 이를 검증해 접근을 허용한다.

JWT(JSON Web Token)의 이해

JWT의 구조 (헤더, 페이로드, 시그니처)

JWT는 인증 정보를 JSON 형태로 인코딩한 후 서명하여 안전하게 전달하는 토큰 기반 인증 방식이다.
서버는 토큰의 서명을 검증함으로써 사용자의 신뢰성을 확인한다.

Header: 토큰 타입(JWT)과 서명 알고리즘 정보 포함
Payload: 사용자 정보 및 토큰 만료 시간 등의 클레임(Claim) 데이터 저장
Signature: 비밀키로 서명된 해시값으로, 데이터 위·변조 여부 검증

JWT 생성 및 검증 원리

JWT 생성 및 검증 원리는 다음과 같다.

사용자가 로그인하면 서버는 사용자 정보를 기반으로 Header, Payload, Signature를 생성하여 JWT를 발급한다.
클라이언트는 요청 시 이 토큰을 Authorization: Bearer <JWT> 형태로 서버에 전송한다.
서버는 서명(Signature)을 비밀키로 검증하여 토큰의 위·변조 여부와 유효 시간을 확인한 뒤 접근을 허용한다

토큰 관리와 보안 고려사항

구분	고려사항	설명
저장 위치	안전한 저장소 사용	토큰은 `LocalStorage`보다 `HttpOnly` 쿠키에 저장하는 것이 안전합니다
전송 방식	HTTPS 사용	네트워크 구간에서 토큰 탈취를 막기 위해 반드시 암호화된 통신을 사용합니다
만료 관리	유효 기간 설정	토큰에 짧은 만료 시간(Expiration)을 지정하여 탈취 시 위험을 줄입니다
재발급 정책	Refresh Token 활용	Access Token 만료 시 사용자 재인증 없이 안전하게 갱신할 수 있도록 설계합니다
무효화 처리	서버 블랙리스트 관리	로그아웃·탈취 의심 시 폐기된 토큰을 서버 측에서 차단합니다
권한 검증	최소 권한 부여	토큰 클레임에는 필요한 권한만 포함시켜 오남용을 방지합니다
위·변조 방지	서명(Signature) 검증	서버는 비밀키로 서명을 검증하여 토큰 위조 여부를 확인합니다

Refresh 토큰의 이해

Access 토큰과 Refresh 토큰의 역할

Access 토큰: 보호 자원에 직접 접근하기 위해 발급되는 단기 유효 자격 증명이다.
Refresh 토큰: 만료된 Access 토큰을 재발급 받기 위해 사용하는 장기 유효 자격 증명이다.

구분	Access 토큰	Refresh 토큰
정의	자원 접근용 단기 인증 토큰	재발급용 장기 인증 토큰
역할	API 요청 시 인증 수행	만료된 Access 토큰 재발급
유효 기간	짧음 (수분~수시간)	김 (며칠~주 단위)
사용 시점	요청 시 서버로 전송	Access 토큰 만료 시 재발급 요청
저장 위치	클라이언트 (주로 쿠키 또는 메모리)	서버 또는 안전한 저장소
보안 위험	탈취 시 즉시 자원 접근 가능	탈취 시 재발급 악용 가능
관리 방식	자동 만료 처리	토큰 회전(Rotation), 블랙리스트 관리 필요

토큰 갱신 워크플로우

토큰 갱신 워크플로우는 Access 토큰이 만료될 때 Refresh 토큰을 이용해 새로운 Access 토큰을 발급받는 절차이다. 이를 통해 사용자는 다시 로그인하지 않고도 인증 상태를 지속적으로 유지할 수 있다.

토큰 만료 및 무효화 처리

토큰 만료는 설정된 유효 시간이 지나 더 이상 인증에 사용할 수 없게 되는 상태를 의미한다.
무효화 처리는 사용자가 로그아웃 하거나 토큰이 탈취된 경우, 서버에서 해당 토큰을 블랙리스트 처리해 재사용을 차단하는 절차다. 이를 통해 불법 접근을 방지하고 인증 시스템의 보안성을 유지한다

인가(Authorization)와 권한 관리

인가(Authorization)의 개념

인증과 인가의 차이점

인증(Authentication): 사용자의 신원을 확인하는 과정으로, ‘누구인지’를 증명하는 절차다.
인가(Authorization): 인증된 사용자가 ‘무엇을 할 수 있는지’를 결정하는 접근 권한 부여 절차다.
즉, 인증은 신원 확인이고 인가는 권한 부여로, 인증이 먼저 이뤄진 후 인가가 수행된다.

인가의 필요성

구분	설명
접근 통제	인증된 사용자라도 허용된 자원에만 접근하도록 제한
보안 강화	민감한 정보를 보호하고 비인가된 접근을 차단
데이터 무결성 유지	권한이 없는 변경을 방지하여 시스템의 신뢰성 유지
감사 및 추적	접근 이력을 기록하여 보안 사고 대응 및 감사 수행 가능

인가의 역할

구분	설명
권한 부여	사용자나 그룹별로 수행 가능한 작업을 정의
리소스 보호	API, DB, 파일 등 주요 자원에 대한 접근을 제어
역할 기반 제어 (RBAC)	역할(Role)에 따라 접근 권한을 일괄적으로 관리
서비스 안정성 유지	불필요한 권한 사용을 방지하여 시스템 안정성 확보

인증 후 인가 프로세스의 이해

인증 후 인가 프로세스는 사용자의 신원을 확인한 뒤, 해당 사용자가 접근할 수 있는 자원과 기능을 결정하는 절차이다. 인증(Authentication)을 통해 신원을 검증하고, 인가(Authorization)를 통해 권한을 부여한다.
이를 통해 시스템은 보안을 유지하고 사용자는 허용된 범위 내에서만 서비스를 이용한다.

권한 기반 접근 제어

역할 기반 접근 제어(RBAC, Role-Based Access Control) 이해

역할 기반 접근 제어(RBAC)은 사용자의 역할(Role)에 따라 시스템 자원에 대한 접근 권한을 부여하는 방식이다.
개별 사용자에게 직접 권한을 지정하지 않고 역할 단위로 관리함으로써 효율성을 높인다.
대규모 시스템에서 권한 관리의 일관성과 보안성을 강화하는 접근 제어 모델이다.

권한 설계 및 구현 방법

권한 설계는 사용자(users), 역할(roles), 매핑(users_roles) 테이블을 기반으로 다대다 관계로 구현한다.
사용자는 여러 역할을 가질 수 있고, 역할은 여러 사용자에게 부여될 수 있다.
역할별 권한 매핑을 통해 최소 권한 원칙(Principle of Least Privilege)을 적용한다.

권한 검증 플로우

사용자가 요청을 보내면 시스템은 먼저 인증 토큰이나 세션을 확인한다.
인증이 성공하면 사용자에게 부여된 역할(role)을 조회하여 접근 가능한 자원을 판단한다.
요청 자원의 접근 권한이 없을 경우 접근이 거부되고, 권한이 있을 경우 정상 처리된다.

OAuth와 OpenID Connect

OAuth의 개념과 필요성

접근 권한 위임의 필요성

접근 권한 위임의 필요성은 사용자가 자격 증명을 직접 공유하지 않고도 제3자 서비스가 제한된 범위 내에서 자원에 접근하도록 하기 위함이다. 예를 들어 과거 핀테크 업계에서는 사용자의 인증정보를 기본으로 웹사이트에 대신 로그인하는 스크래핑을 활용하여 서비스를 활용하였다.
→ 스크래핑 방식은 사용자의 계정 정보가 제3자에게 노출되어 보안 위험이 높았다.

OAuth의 정의와 목적

OAuth는 사용자 자격 증명을 직접 노출하지 않고, 제3자 애플리케이션이 제한된 권한으로 자원에 접근할 수 있도록 하는 인증 위임 프로토콜이다. Access Token을 기반으로 안전하게 API 자원에 접근할 수 있도록 설계되었다. RFC 6749 표준에 따라 다양한 플랫폼 간 인증 연동을 지원한다.

OAuth 주체와 설정

OAuth의 주요 주체 (유저, 클라이언트, 인가 서버, 리소스 서버)

사용자(User): 자신의 자원 접근을 제3자 애플리케이션에 위임하는 주체이다.
클라이언트(Client): 사용자의 인가를 받아 보호된 자원에 접근하려는 애플리케이션이다.
인가 서버(Authorization Server): 사용자 인증과 인가를 수행하고 Access Token을 발급하는 서버이다.
리소스 서버(Resource Server): Access Token을 검증하고 보호된 사용자 데이터를 제공하는 서버이다.

Client ID와 Client Secret

클라이언트 ID(Client ID): 인가 서버가 클라이언트를 식별하기 위해 발급하는 고유 식별자이다.
클라이언트 시크릿(Client Secret): 인가 서버와 클라이언트 간의 신뢰를 검증하기 위해 사용하는 비밀키이다.

권한 범위(Scope) 설정

Scope는 클라이언트가 리소스 서버에 요청할 때 사용자 데이터 접근 범위를 명시하는 설정이다.
OAuth에서 Scope는 허용된 권한의 한계를 정의하여 최소 권한 원칙을 보장한다.

구분	Scope 예시	설명
기본 정보	`profile`, `email`	사용자 이름, 이메일 등 기본 프로필 정보에 접근
소셜 서비스	`friends`, `photos`	친구 목록, 사진 앨범 등 소셜 네트워크 리소스에 접근
오픈ID	`openid`	사용자 인증용 ID Token 요청 (OIDC 표준에서 사용)
오프라인 접근	`offline_access`	Refresh Token 발급을 허용하여 장기 인증 유지 가능
커스텀	`read:posts`, `write:comments`	특정 리소스의 읽기·쓰기 등 세분화된 접근 권한 부여

OAuth 워크플로우

OAuth 워크플로우는 클라이언트가 사용자 대신 리소스에 접근하기 위해 인가 코드를 발급받고 토큰을 교환하는 과정이다. 단계는 아래와 같다.

단계	설명
1단계	클라이언트가 사용자에게 권한을 요청(인가 요청 URL로 리다이렉트)
2단계	사용자가 접근을 승인하면 인가 서버가 인가 코드를 발급하여 리다이렉트 URI로 전달
3단계	클라이언트가 받은 인가 코드를 백엔드 서버로 전달
4단계	인가 서버가 인가 코드(및 클라이언트 인증, PKCE 검증 등)를 확인하고 Access Token 발급
5단계	클라이언트가 발급받은 토큰으로 리소스 서버에 API 요청
6단계	리소스 서버가 토큰을 검증한 뒤 요청한 자원을 응답

Authorization Code 플로우

Authorization Code 플로우는 서버 기반 애플리케이션에서 사용하는 표준 인증 방식이다.
사용자가 로그인 승인 후 인가 코드를 발급받고, 클라이언트는 이를 이용해 Access Token을 안전하게 교환한다. 토큰이 직접 노출되지 않아 보안성이 높은 인증 절차이다.

Implicit 플로우

Implicit 플로우는 클라이언트 측 애플리케이션(SPA 등)에서 사용되는 간소화된 OAuth 인증 방식이다.
인가 코드 교환 과정 없이 Access Token을 브라우저에서 직접 발급받는다.
보안 수준은 낮지만 빠른 인증이 필요한 환경에 적합한 방식이다.

각 플로우의 보안 특성 비교

구분	Authorization Code 플로우	Implicit 플로우
토큰 전달 방식	인가 코드를 통해 서버에서 Access Token 발급	브라우저에서 직접 Access Token 발급
사용 환경	서버 기반 애플리케이션	클라이언트(SPA, 모바일 앱 등)
보안 수준	높음 (토큰이 직접 노출되지 않음)	낮음 (URL을 통해 토큰이 노출될 수 있음)
Refresh Token 사용	가능	불가능
대표 특징	안전하지만 과정이 다소 복잡함	빠르지만 보안 위험이 존재함

OpenID Connect(OIDC)

OIDC 개념 및 OAuth와 OIDC의 관계

OIDC(OpenID Connect)는 OAuth 2.0 프로토콜을 확장하여 사용자 인증(Authentication) 기능을 추가한 표준이다.
OAuth가 리소스 접근 권한 위임을 담당한다면, OIDC는 사용자 신원 검증과 프로필 정보 제공을 담당한다.
즉, OAuth는 “인가(Authorization)”, OIDC는 “인증(Authentication)”을 수행하는 관계이다.

ID 토큰의 개념과 활용

ID 토큰은 사용자 인증 결과를 포함하는 JWT(JSON Web Token) 형태의 토큰이다.
OAuth의 Access Token과 달리 사용자 신원(Identity) 확인에 사용된다.
로그인 상태 유지나 SSO(Single Sign-On) 구현에 활용되는 핵심 요소이다.

Jerry

Backend engineer

이전 포스트

[강의] Docker 빌드/배포/컨테이너 실행하기

다음 포스트