🔐 접근통제 → 인증 → 시스템 인증 → 인증 수단의 종류
- 접근통제: 특정 사용자나 시스템이 어떤 자원에 접근할 수 있는지를 제한하는 것
- 인증(Authentication): 그 전에, 누군지 확인부터 해야겠지?
→ "너 누구야?"를 묻는 단계 - 시스템 인증: 사용자가 주장하는 신원을 시스템이 검증하는 것
→ 이때 어떤 방법으로 **'누군지 확인하느냐'**에 따라 인증 수단을 분류해
📂 시스템 인증 수단의 분류
시스템은 사용자의 신원을 확인하기 위해 다음 5가지 중 하나 이상을 사용해.
키워드는 "사용자가 무엇을 알고 있는가, 가지고 있는가, 있는가, 하는가, 어디 있는가"
| 1. 지식기반 인증 | 사용자가 알고 있는 정보 | 비밀번호, PIN 번호, 패스프레이즈 |
| 2. 소유기반 인증 | 사용자가 가지고 있는 물건 | OTP 토큰, 스마트카드, 보안 USB, 인증서 |
| 3. 존재기반 인증 | 사용자의 신체적 특성 | 지문, 홍채, 얼굴 인식, 정맥, 음성 |
| 4. 행위기반 인증 | 사용자의 행동 패턴 | 키 입력 속도, 마우스 움직임, 걸음걸이 |
| 5. 위치기반 인증 | 사용자의 접근 위치 | GPS, IP 주소, 기지국 |
---------------------------------------------------------------------------------------------------------------------------------------
🧩 세션(Session. 옛날 방식)
"서버와 클라이언트 간에 연결이 유지되는 동안의 상태 또는 정보 저장 공간"
좀 더 쉽게 말하면:
"사용자 한 명이 웹사이트에 로그인해서 로그아웃할 때까지의 시간 동안 서버가 '이 사람'을 기억하기 위한 기술"
🤔 왜 세션이 필요할까?
웹은 기본적으로 HTTP 프로토콜을 사용해
그런데 HTTP는 어떤 특징이 있냐면?
✅ 무상태(stateless) 프로토콜이다!
즉,
- 너가 로그인을 했든
- 장바구니에 상품을 담았든
- 서버는 다음 요청에서 그게 누군지 전혀 기억하지 못해
그래서 등장한 게 세션!
"이 사용자가 보낸 다음 요청도, 같은 사람이 보낸 거라고 기억하자!"
📦 세션의 구조 (기본 흐름)
- 사용자가 로그인하면
- 서버가 세션 ID를 하나 만들어서
- 이 세션 ID를 사용자 브라우저에 저장 (쿠키에 저장하는 경우가 많음)
- 다음 요청 때마다, 이 세션 ID를 보내오면
- 서버는 "아 이거 아까 로그인한 그 사람이구나!"라고 인식
💡 실제 비유
세션은 놀이공원 입장권에 붙은 팔찌 같은 거야.
- 팔찌를 차면 (세션 ID 발급됨)
- 어트랙션 탈 때마다 팔찌 보여주면 "어, 입장한 사람 맞네~"라고 해줌
- 팔찌를 잃어버리면? 다시 입장 절차 밟아야 함
💾 세션은 서버가 관리한다
| 세션 ID | 사용자마다 하나씩 부여되는 고유값 |
| 저장 위치 | 서버 메모리, DB, 파일 등 |
| 클라이언트는? | 보통 쿠키에 세션 ID만 저장 |
즉, 중요한 정보는 서버가 갖고 있고
클라이언트(브라우저)는 그저 세션 ID만 기억
🔐 세션 vs 쿠키 비교
| 저장 위치 | 서버 | 클라이언트(브라우저) |
| 보안성 | 비교적 안전 | 노출 위험 있음 |
| 사용 예 | 로그인 상태 유지 | 자동 로그인, 광고 추적 |
| 수명 | 브라우저 닫으면 종료(default) | 설정한 기간까지 유지 가능 |
🧠 세션이 실제로 어디에 쓰이나?
- 사용자 로그인 상태 유지
- 장바구니 정보 저장
- 게시글 작성 중인 사용자 확인
- 보안 인증 유지
- 서버 간 사용자 상태 공유 (SSO)
🧪 정보처리기사 실기 예상 문제
[단답형]
HTTP는 비연결성과 무상태성을 가지므로 사용자의 상태를 유지하기 위해 서버에 저장하는 정보는?
→ 세션(Session)
-------------------------------------------------------------------------------------------------------------------------------------
🧩 AAA
Authentication, Authorization, Accounting
즉, 인증, 인가, 계정관리(혹은 과금)
이 세 단어의 앞글자를 따서 AAA라고 불러.
**"사용자가 네트워크나 시스템을 사용할 때, 누군지 확인하고, 뭘 할 수 있는지 결정하고, 사용 내역을 기록"**하는 일련의 흐름이야.
🔍 AAA 구성요소 상세
| Authentication (인증) | "너 누구야?" | 사용자의 신원을 확인 (ID/PW, 지문 등) |
| Authorization (인가) | "그래서 너 뭘 해도 돼?" | 인증된 사용자가 접근 가능한 자원을 결정 |
| Accounting (계정관리/과금) | "뭐 했는지 기록하자" | 사용자의 활동을 기록/모니터링 (로그, 과금 등) |
🔒 AAA가 왜 필요할까?
✅ 시스템을 안전하게 보호하려면:
- 아무나 들어오면 안 되니까 → 인증
- 아무나 다 할 수 있으면 위험하니까 → 인가
- 누가 뭐했는지 추적이 가능해야 하니까 → 계정 관리
→ 그래서 대부분의 보안 프로토콜이나 시스템은 AAA를 기반으로 설계돼
📡 AAA 관련 프로토콜
AAA 구조를 사용하는 대표적인 프로토콜도 시험에서 잘 나와.
| RADIUS | Remote Authentication Dial-In User Service 원격 접속 사용자 인증/인가/회계 |
| TACACS+ | Terminal Access Controller Access-Control System Plus 네트워크 장비용 인증/인가 |
| Diameter | RADIUS의 확장판 (확장성↑) |
| Kerberos | 대칭키 기반 인증 프로토콜 |
| OAuth | 토큰 기반 인가 프로토콜 |
🧪 실기 스타일 예상 문제
[단답형]
네트워크 보안에서 인증(Authentication), 인가(Authorization), 계정 관리(Accounting)를 아우르는 용어는?
→ AAA
---------------------------------------------------------------------------------------------------------------------------------------
🧩 접근 통제 정책
시스템 자원(예: 파일, 데이터베이스, 네트워크 등)에 대해
“누가, 무엇을, 언제, 어떻게 접근할 수 있는지”를 정하는 규칙
즉, 사용자가 마음대로 아무 데나 접근하지 못하게 **규칙(정책)**을 만들어두는 거야.
📚 대표적인 접근 통제 정책 3가지
| 1️⃣ MAC | 강제적 접근 통제 (Mandatory Access Control) | 관리자가 모든 권한 결정 | 군대식, 강력한 보안 문서에 ‘기밀’ 등급 → ‘3급 이상만 열람 가능’ |
| 2️⃣ DAC | 임의적 접근 통제 (Discretionary Access Control) | 소유자가 권한 제어 | 유연함, 보안 약함 내가 만든 파일을 누구에게 읽기/쓰기 허용할지 직접 설정 가능 |
| 3️⃣ RBAC | 역할 기반 접근 통제 (Role-Based Access Control) | 역할(Role) 단위로 권한 부여 | 기업/조직 시스템에 적합 ‘인사팀 직원’은 인사 DB 열람 가능, ‘개발자’는 소스코드 저장소 접근 가능 등 |
[단답형]
사용자가 소유한 자원에 대해 접근 권한을 자유롭게 부여하는 정책은?
→ DAC
'정보처리기사 > 이론설명' 카테고리의 다른 글
| [이론설명 이기적] 제품 소프트웨어 패키징 (2) | 2025.08.07 |
|---|---|
| [이론설명 이기적] 대칭키, 공개키, 해시 암호화 (3) | 2025.08.02 |
| [이론설명 이기적] 통신 프로토콜 (OSI 7, TCP/IP) (5) | 2025.08.01 |
| [이론설명 이기적] 통신망 기술 (7) | 2025.07.31 |
| [이론설명 이기적] 네트워크 구축관리 (0) | 2025.07.28 |
