빈출 서술형 50개 암기훈련

시스템보안 서술형 8개
네트워크보안 서술형 8개
어플리케이션보안 서술형 10개
암호·접근통제·보안모델 서술형 10개
관리·법규·개인정보 서술형 14개

총 50개

압축 답안: 시험장에서 바로 쓸 수 있는 2~4문장 답안
채점 키워드: 반드시 포함해야 할 핵심 용어
부분점 기준: 기본점, 핵심점, 가점을 가르는 요소
감점 포인트: 혼동, 누락, 부정확한 표현으로 감점되는 지점
답안 구조: 절차형·비교형·상황형 문제에서 답안을 배열하는 순서

개념 정의
→ 위험 또는 발생 원인
→ 대응 방안

SQL Injection은 사용자 입력값에 SQL 구문을 삽입하여 DB를 비정상적으로 조회, 수정, 삭제하거나 인증을 우회하는 공격이다.
주요 원인은 사용자 입력값을 SQL 문자열에 직접 결합하는 것이다.
대응 방안으로 Prepared Statement, 입력값 검증, DB 권한 최소화, 오류 메시지 제한, WAF 적용이 있다.

정의만 쓰고 대응 방안이 없음
대응 방안이 1개뿐임
핵심 키워드를 누락함
비슷한 개념을 혼동함
기술적 대책만 쓰고 관리적 대책을 빠뜨림

계정 관리를 위해 불필요한 계정, 기본 계정, 퇴사자 계정, 휴면 계정을 삭제하거나 비활성화해야 한다. 또한 공유 계정 사용을 제한하고 사용자별 개별 계정을 부여하여 책임추적성을 확보해야 하며, 관리자 권한은 최소한의 사용자에게만 부여하고 계정 생성·변경·삭제 이력을 기록해야 한다.

불필요 계정 제거
퇴사자 계정 비활성화
휴면 계정 잠금
공유 계정 제한
관리자 권한 최소화
계정 이력 관리

비밀번호 정책만 쓰고 계정 생명주기 관리를 빠뜨리면 감점
공유 계정의 책임추적성 문제를 빠뜨리면 감점

패스워드 보안을 위해 충분한 길이와 복잡도, 이전 비밀번호 재사용 제한, 초기 비밀번호 변경, 로그인 실패 횟수 제한을 적용해야 한다. 또한 비밀번호는 평문으로 저장하지 않고 사용자별 솔트를 적용한 해시값으로 저장하며, 중요 계정에는 MFA를 적용해야 한다.

길이
복잡도
재사용 제한
실패 횟수 제한
솔트 해시
MFA

비밀번호 암호화라고만 쓰고 솔트 해시를 누락하지 말 것
평문 저장 금지를 반드시 포함할 것

최소권한 원칙은 사용자나 프로세스에 업무 수행에 필요한 최소한의 권한만 부여하는 보안 원칙이다. 이를 통해 권한 오남용을 방지하고, 계정 탈취나 시스템 침해가 발생했을 때 피해 범위를 줄일 수 있다.

필요한 최소 권한
업무 수행 범위
권한 오남용 방지
피해 범위 축소

“권한을 제한한다”만 쓰면 약함
왜 필요한지, 즉 오남용 방지와 피해 축소를 함께 쓸 것

777 권한은 소유자, 그룹, 기타 사용자 모두에게 읽기·쓰기·실행 권한을 부여하는 설정이다. 모든 사용자가 파일을 수정하거나 실행할 수 있어 파일 변조, 악성코드 실행, 권한 오남용 위험이 있으므로 필요한 최소 권한만 부여해야 한다.

모든 사용자 rwx
쓰기 권한 위험
실행 권한 위험
파일 변조
최소권한

777을 단순히 “강한 권한”이라고만 쓰지 말 것
읽기·쓰기·실행이 모두에게 부여된다는 점을 명확히 쓸 것

SetUID는 실행 파일을 실행할 때 파일 소유자의 권한으로 실행되도록 하는 특수 권한이다. root 소유 SetUID 파일에 취약점이 있으면 일반 사용자가 root 권한으로 명령을 실행하는 권한 상승이 발생할 수 있으므로 불필요한 SetUID 파일을 점검하고 제거해야 한다.

파일 소유자 권한으로 실행
root SetUID
권한 상승
불필요 파일 점검

Sticky Bit와 혼동하지 말 것
SetUID는 “소유자 권한으로 실행”이 핵심

로그는 침해사고 탐지, 원인 분석, 책임추적성 확보에 필요한 핵심 자료이다. 따라서 인증, 권한 변경, 관리자 작업, 오류, 보안 이벤트 로그를 수집하고, 시간 동기화, 접근통제, 무결성 보호, 보관기간 설정, 정기 점검을 적용해야 한다.

침해사고 탐지
원인 분석
책임추적성
시간 동기화
접근통제
무결성 보호
보관기간
정기 점검

로그 수집만 쓰면 부족
보관, 보호, 점검까지 써야 고득점

로그의 목적을 탐지, 원인 분석, 책임추적성 중 2개 이상으로 쓰면 기본점
수집 대상에 인증, 권한 변경, 관리자 작업, 보안 이벤트 중 2개 이상을 포함하면 가점
시간 동기화, 접근통제, 무결성 보호, 보관기간, 정기 점검을 관리 방안으로 쓰면 고득점

패치관리는 운영체제와 소프트웨어의 알려진 취약점과 오류를 보완하여 침해사고 가능성을 줄이기 위한 활동이다. 자산과 버전을 파악하고 패치 정보를 수집한 뒤, 중요도 평가, 테스트, 백업과 롤백 계획, 운영 적용, 결과 검증, 이력 관리 절차로 수행해야 한다.

자산·버전 파악
패치 정보 수집
중요도 평가
테스트
백업
롤백
적용
검증
이력 관리

운영 서버에 바로 적용한다고 쓰면 위험
테스트와 롤백 계획을 반드시 포함

목적: 알려진 취약점과 오류 보완
절차: 자산·버전 파악 → 패치 정보 수집 → 중요도 평가 → 테스트 → 백업·롤백 계획 → 적용 → 검증 → 이력 관리
주의: 운영 영향과 장애 가능성을 사전에 통제

패치관리의 목적을 취약점 보완으로 쓰면 기본점
테스트, 백업, 롤백 계획을 포함하면 핵심점
적용 후 검증과 이력 관리를 포함하면 가점

랜섬웨어 감염이 의심되면 감염 시스템을 네트워크에서 격리하여 확산을 방지하고, 감염 범위와 악성 파일, 로그, 외부 통신 여부를 분석해야 한다. 이후 악성코드를 제거하고 신뢰할 수 있는 백업본으로 복구하며, 보안패치, EDR, 접근권한 점검, 사용자 교육, 오프라인 백업 등 재발 방지 대책을 수행해야 한다.

격리
감염 범위 분석
악성코드 제거
백업 복구
보안패치
EDR
사용자 교육
오프라인 백업

복구만 쓰지 말 것
격리, 분석, 재발 방지를 함께 써야 함

TCP는 연결 지향 프로토콜로 연결 설정 후 순서 보장, 오류 제어, 재전송을 통해 신뢰성 있는 전송을 제공한다. UDP는 비연결 지향 프로토콜로 신뢰성은 낮지만 구조가 단순하고 빠르며 DNS, 음성, 스트리밍 등 실시간성이 중요한 서비스에 사용된다.

TCP = 연결 지향
UDP = 비연결 지향
신뢰성
순서 보장
재전송
속도

TCP와 UDP를 모두 “전송 계층”이라고만 쓰면 부족
연결성, 신뢰성, 속도 차이를 써야 함

ARP Spoofing은 거짓 ARP 정보를 보내 IP 주소와 MAC 주소의 매핑을 조작하는 공격이다. 이를 통해 피해자의 트래픽을 공격자에게 유도하여 스니핑이나 중간자 공격이 발생할 수 있으며, 대응 방안으로 정적 ARP 설정, Dynamic ARP Inspection, DHCP Snooping, ARP 변경 모니터링, 네트워크 분리, 암호화 통신을 적용할 수 있다.

거짓 ARP
IP-MAC 매핑 조작
스니핑
MITM
정적 ARP
DAI
DHCP Snooping
암호화 통신

DNS Spoofing과 혼동하지 말 것
ARP는 IP-MAC 매핑 조작

DNS Spoofing은 DNS 응답을 위조하여 정상 도메인을 공격자가 지정한 IP 주소로 연결하게 만드는 공격이다. DNS Cache Poisoning은 DNS 서버의 캐시에 위조된 DNS 정보를 저장시켜 다수 사용자를 가짜 사이트로 유도할 수 있는 공격이다.

DNS 응답 위조
도메인-IP 매핑 조작
가짜 사이트 유도
캐시 오염

ARP처럼 MAC 주소 조작이라고 쓰면 오답
DNS는 도메인과 IP 연결 조작

MITM은 통신 당사자 사이에 공격자가 개입하여 데이터를 도청하거나 변조하고 인증 정보를 탈취하는 공격이다. 대응 방안으로 HTTPS/TLS 적용, 인증서 검증, HSTS, VPN 사용, ARP Spoofing 탐지, DNSSEC 적용, 공용 Wi-Fi 사용 주의, MFA 적용 등이 있다.

중간자
도청
변조
인증정보 탈취
TLS
인증서 검증
VPN
MFA

단순 도청만 쓰면 스니핑과 구분이 약함
중간에서 개입해 변조할 수 있다는 점을 포함

Replay Attack은 정상 인증 메시지나 요청을 공격자가 가로챈 뒤 다시 전송하여 인증 우회나 중복 처리를 유발하는 공격이다. 대응 방안으로 Nonce, Timestamp, Sequence Number, MAC 또는 전자서명 검증을 적용하여 요청의 재사용을 방지해야 한다.

정상 요청 재전송
인증 우회
중복 처리
Nonce
Timestamp
Sequence Number
MAC

DDoS와 혼동하지 말 것
Replay는 “재전송”이 핵심

SYN Flooding은 TCP 3-Way Handshake 과정에서 다수의 SYN 요청을 보내고 최종 ACK를 보내지 않아 서버의 연결 대기 자원을 고갈시키는 공격이다. 대응 방안으로 SYN Cookie 적용, 연결 대기 큐와 타임아웃 조정, SYN 요청 Rate Limiting, 방화벽·IPS 탐지, DDoS 방어 서비스 활용 등이 있다.

TCP 3-Way Handshake
SYN
ACK 미전송
Half-open
자원 고갈
SYN Cookie
Rate Limiting

단순히 “트래픽을 많이 보낸다”만 쓰면 부족
3-Way Handshake 악용을 써야 함

IDS는 네트워크나 시스템의 트래픽과 이벤트를 분석하여 침입 시도나 이상 행위를 탐지하고 관리자에게 경고하는 시스템이다. IPS는 침입을 탐지한 후 실시간으로 차단까지 수행하는 시스템으로 즉시 대응이 가능하지만, 오탐 시 정상 트래픽이 차단될 수 있다.

IDS = 탐지·경고
IPS = 탐지·차단
오탐
정상 트래픽 차단 가능

IDS도 차단한다고 쓰면 부정확
IPS의 오탐 위험도 쓰면 좋음

일반 방화벽은 주로 IP 주소, 포트 번호, 프로토콜을 기준으로 네트워크 접근을 통제하는 장비이다. WAF는 HTTP/HTTPS 요청의 URL, 파라미터, 쿠키, 헤더, 본문을 분석하여 SQL Injection, XSS, 파일 업로드 공격 등 웹 애플리케이션 공격을 탐지·차단하는 7계층 보안장비이다.

일반 방화벽 = IP·포트·프로토콜
WAF = HTTP 요청 분석
7계층
SQL Injection
XSS
파일 업로드 공격

WAF를 그냥 방화벽이라고만 쓰면 부족
웹 요청 분석과 웹 공격 차단을 포함

HTTP는 각 요청을 독립적으로 처리하며 이전 요청 상태를 자동으로 기억하지 않는 무상태 프로토콜이다. 따라서 로그인 상태와 사용자 식별 정보를 유지하기 위해 쿠키와 세션을 사용하며, 일반적으로 서버는 세션을 생성하고 클라이언트는 세션 ID를 쿠키로 전송한다.

무상태
이전 요청 기억하지 않음
로그인 상태 유지
쿠키
세션
세션 ID

HTTP가 상태를 자동 저장한다고 쓰면 오답
쿠키·세션이 왜 필요한지 연결해야 함

GET은 주로 조회에 사용되며 요청 데이터가 URL에 포함될 수 있어 브라우저 기록이나 로그에 남기 쉬우므로 민감정보 전송에 부적절하다. POST는 요청 본문에 데이터를 포함하지만 HTTPS가 없으면 암호화가 보장되지 않으므로 로그인 정보나 개인정보 전송 시 HTTPS를 적용해야 한다.

GET = URL
POST = Body
민감정보
로그 노출
HTTPS

POST는 무조건 안전하다고 쓰면 감점
HTTPS 필요를 반드시 포함

HttpOnly는 JavaScript에서 쿠키에 접근하지 못하도록 하여 XSS로 인한 쿠키 탈취 위험을 줄인다. Secure는 HTTPS 통신에서만 쿠키가 전송되도록 하며, SameSite는 다른 사이트에서 발생한 요청에 쿠키가 자동 전송되는 것을 제한하여 CSRF 위험을 완화한다.

HttpOnly = JavaScript 접근 제한
Secure = HTTPS
SameSite = CSRF 완화

HttpOnly와 Secure를 바꿔 쓰지 말 것
SameSite는 CSRF와 연결

SQL Injection은 웹 애플리케이션의 입력값에 악의적인 SQL 구문을 삽입하여 데이터베이스를 비정상적으로 조회, 수정, 삭제하거나 인증을 우회하는 공격이다. 대응 방안으로 SQL 구조와 입력값을 분리하는 Prepared Statement를 사용하고, 입력값 검증, DB 권한 최소화, 오류 메시지 노출 제한, WAF 적용, 로그 모니터링을 수행해야 한다.

SQL 구문 삽입
DB 공격
인증 우회
Prepared Statement
입력값 검증
DB 권한 최소화
오류 메시지 제한

입력값 검증만 쓰면 부족
Prepared Statement를 반드시 포함

개념: 입력값에 SQL 구문을 삽입해 DB를 비정상 조작
원인: 입력값을 SQL 문자열에 직접 결합
대응: Prepared Statement, 입력값 검증, DB 권한 최소화, 오류 메시지 제한

SQL 구문 삽입과 DB 조회·수정·삭제 또는 인증 우회를 쓰면 기본점
Prepared Statement를 핵심 대응으로 쓰면 핵심점
DB 권한 최소화, 오류 메시지 제한, WAF, 로그 모니터링을 추가하면 가점

XSS는 웹 애플리케이션이 사용자 입력값을 안전하게 처리하지 않아 악성 스크립트가 다른 사용자의 브라우저에서 실행되는 공격이다. 이를 통해 쿠키 탈취, 세션 하이재킹, 피싱, 화면 변조가 발생할 수 있으며, 대응 방안으로 출력값 인코딩, 입력값 검증, CSP 적용, HttpOnly·Secure 쿠키 설정, WAF 적용 등이 있다.

악성 스크립트
사용자 브라우저
쿠키 탈취
출력값 인코딩
CSP
HttpOnly

입력값 검증만 쓰고 출력 위치별 인코딩을 누락하면 감점
DB 쿼리 조작이나 인증 우회만 설명하면 SQL Injection과 혼동한 답안으로 감점

악성 스크립트가 사용자 브라우저에서 실행된다고 쓰면 기본점
쿠키 탈취, 세션 하이재킹, 피싱 등 피해를 1개 이상 쓰면 가점
출력값 인코딩을 핵심 대응으로 쓰고 CSP, HttpOnly·Secure 쿠키를 보조 대책으로 쓰면 고득점

Stored XSS는 악성 스크립트가 게시글이나 댓글처럼 서버에 저장된 뒤 이를 조회하는 사용자 브라우저에서 실행되는 공격이다. Reflected XSS는 요청 파라미터가 서버 응답에 반사되어 실행되는 공격이며, DOM-based XSS는 클라이언트 측 JavaScript가 외부 입력값을 안전하지 않게 DOM에 삽입하여 발생하는 공격이다.

Stored = 서버 저장
Reflected = 요청 반사
DOM-based = 클라이언트 DOM 처리

Stored와 Reflected를 바꿔 쓰지 말 것
DOM-based는 서버 저장 여부보다 브라우저 측 처리에 초점

CSRF는 사용자가 웹사이트에 로그인된 상태를 악용하여 사용자가 의도하지 않은 요청을 서버에 전송하게 만드는 공격이다. 대응 방안으로 예측 불가능한 CSRF Token을 생성해 서버에서 검증하고, SameSite 쿠키 설정, Origin/Referer 검증, 중요 기능 재인증, GET 방식의 상태 변경 금지를 적용해야 한다.

로그인 상태 악용
원치 않는 요청
CSRF Token
SameSite
Origin/Referer
재인증

악성 스크립트 실행이라고 쓰면 XSS와 혼동
CSRF는 요청 위조

파일 업로드 취약점은 업로드 파일의 확장자, 내용, 크기, 저장 위치, 실행 권한 등을 검증하지 않아 웹셸이나 악성 파일이 서버에 업로드·실행될 수 있는 취약점이다. 대응 방안으로 허용 확장자 방식, MIME Type과 파일 시그니처 검증, 파일 크기 제한, 파일명 난수화, 웹 루트 외부 저장, 업로드 디렉터리 실행 권한 제거, 접근통제, 악성코드 검사를 적용해야 한다.

웹셸
악성 파일
허용 확장자
파일 시그니처
웹 루트 외부 저장
실행 권한 제거

확장자 검증만 쓰면 부족
저장 경로 분리와 실행 권한 제거를 반드시 포함

웹셸 또는 악성 파일 업로드·실행 위험을 쓰면 기본점
허용 확장자, MIME Type, 파일 시그니처 검증 중 2개 이상을 쓰면 핵심점
웹 루트 외부 저장, 실행 권한 제거, 파일명 난수화, 악성코드 검사를 포함하면 고득점

IDOR는 사용자가 요청 파라미터의 객체 식별자를 조작하여 권한 없는 타인의 자원에 접근하는 접근통제 취약점이다. 대응 방안으로 서버 측에서 매 요청마다 사용자 권한과 자원 소유자를 검증하고, 역할 기반 접근통제를 적용하며, 단순 순번 ID 노출을 줄이고 비정상 객체 ID 순차 접근을 로그로 모니터링해야 한다.

객체 식별자 조작
타인 자원 접근
서버 측 권한 검증
소유자 검증
로그 모니터링

UUID 사용만 쓰면 부족
핵심은 서버 측 권한 검증

개념: 객체 식별자 조작을 통한 타인 자원 접근
원인: 서버 측 권한 또는 소유자 검증 누락
대응: 매 요청마다 소유자·권한 검증, 권한 없는 요청 차단, 로그 모니터링
보조: 순번 ID 노출 축소, Rate Limiting

객체 식별자 조작과 타인 자원 접근을 모두 쓰면 기본점
서버 측 소유자 검증을 대응으로 쓰면 핵심점
UUID, Rate Limiting, 로그 모니터링은 보조 대책으로 쓰면 가점

API 보안을 위해 모든 요청에 인증을 적용하고, 사용자가 요청한 자원에 접근할 권한이 있는지 서버 측에서 검증해야 한다. 또한 입력값 검증, 응답 데이터 최소화, Rate Limiting, 토큰 만료와 폐기 정책, Mass Assignment 방지, CORS 제한, 오류 메시지 노출 제한, API 호출 로그 기록을 적용해야 한다.

인증
인가
입력값 검증
응답 최소화
Rate Limiting
토큰 관리
Mass Assignment 방지
로그 기록

클라이언트 화면 제어만 쓰면 감점
서버 측 인증·인가 검증이 핵심

대칭키 암호는 암호화와 복호화에 같은 비밀키를 사용하는 방식으로 속도가 빠르고 대량 데이터 암호화에 적합하지만 키 분배가 어렵다. 공개키 암호는 공개키와 개인키 한 쌍을 사용하는 방식으로 키 분배 문제를 완화하고 전자서명과 인증에 활용될 수 있으나 대칭키 방식보다 속도가 느리다.

대칭키 = 같은 키
공개키 = 공개키·개인키
속도
키 분배
전자서명

공개키가 빠르다고 쓰면 감점
대량 데이터 암호화는 대칭키가 적합

대칭키: 같은 키 사용, 빠름, 대량 데이터에 적합, 키 분배 어려움
공개키: 공개키·개인키 쌍 사용, 키 분배 문제 완화, 전자서명 활용, 상대적으로 느림
비교 기준: 키 사용 방식, 속도, 용도, 키 분배

암호화는 기밀성 보호를 위해 평문을 암호문으로 변환하고 올바른 키로 복호화할 수 있는 방식이다. 반면 해시는 임의 길이 데이터를 고정 길이 해시값으로 변환하는 일방향 함수로, 원칙적으로 원문 복원이 불가능하며 무결성 검증과 비밀번호 저장에 활용된다.

암호화 = 기밀성
복호화 가능
해시 = 일방향
고정 길이
무결성

해시를 복호화한다고 쓰면 큰 감점
Base64 같은 인코딩을 암호화로 설명하면 감점

암호화가 키로 복호화 가능한 기밀성 보호 수단임을 쓰면 기본점
해시가 일방향 고정 길이 값이며 원문 복원이 원칙적으로 불가능하다고 쓰면 기본점
무결성 검증과 비밀번호 저장 등 활용 예시를 쓰면 가점

솔트는 비밀번호 해시 계산 시 함께 사용하는 사용자별 임의 값으로, 동일한 비밀번호라도 서로 다른 해시값이 생성되도록 한다. 이를 통해 레인보우 테이블 공격과 동일 비밀번호 사용자 식별을 어렵게 하고, 공격자가 사용자별로 해시를 다시 계산해야 하므로 사전 공격 비용을 증가시킬 수 있다.

사용자별 임의 값
같은 비밀번호 다른 해시
레인보우 테이블 방어
사전 공격 비용 증가

솔트를 비밀키라고 설명하지 말 것
솔트는 보통 비밀이 아니라 고유성과 무작위성이 중요

전자서명은 송신자가 자신의 개인키로 메시지 또는 메시지 해시값에 서명하고, 수신자가 송신자의 공개키로 이를 검증하는 기술이다. 이를 통해 서명자 인증, 데이터 무결성, 부인방지를 제공할 수 있다.

개인키로 서명
공개키로 검증
인증
무결성
부인방지

공개키로 서명하고 개인키로 검증한다고 쓰면 오답

MAC/HMAC은 송수신자가 공유한 비밀키를 이용해 메시지 인증값을 생성하여 무결성과 메시지 인증을 제공한다. 그러나 같은 비밀키를 양측이 공유하므로 제3자에게 누가 생성했는지 증명하기 어려워 부인방지를 제공하기 어렵고, 전자서명은 송신자의 개인키로 서명하고 공개키로 검증하므로 인증, 무결성, 부인방지를 제공한다.

MAC/HMAC = 공유 비밀키
전자서명 = 개인키·공개키
부인방지 차이
무결성
인증

MAC이 부인방지를 제공한다고 쓰면 부정확

PKI는 공개키 암호를 안전하게 사용하기 위해 공개키와 사용자 신원을 인증서로 연결하고 이를 발급·검증·폐지하는 공개키 기반 구조이다. 주요 구성요소로는 인증서를 발급·서명하는 CA, 신청자 신원을 확인하는 RA, 인증서, 인증서 저장소, 폐지 목록인 CRL, 인증서 상태를 실시간 확인하는 OCSP 등이 있다.

공개키 신뢰
인증서
CA
RA
CRL
OCSP

CA와 RA 역할을 바꾸지 말 것
CA는 발급·서명, RA는 신원 확인

개념: 공개키와 사용자 신원을 인증서로 연결하는 신뢰 기반 구조
구성: CA, RA, 인증서, 인증서 저장소, CRL, OCSP
기능: 인증서 발급, 검증, 폐지 상태 확인
주의: CA는 인증서 발급·서명, RA는 신청자 신원 확인

공개키와 신원을 인증서로 연결한다는 개념을 쓰면 기본점
CA와 RA의 역할을 구분하면 핵심점
CRL 또는 OCSP를 폐지 상태 확인 수단으로 쓰면 가점

식별은 사용자가 사용자 ID와 같은 식별자를 제시하여 자신이 누구인지 주장하는 과정이고, 인증은 그 신원이 실제로 맞는지 확인하는 절차이다. 인가는 인증된 사용자가 특정 자원이나 기능에 접근할 권한이 있는지 확인하는 절차이며, 책임추적성은 시스템 행위의 주체를 로그 등을 통해 추적할 수 있는 성질이다.

식별 = ID 제시
인증 = 신원 확인
인가 = 권한 확인
책임추적성 = 로그로 추적

인증과 인가를 바꿔 쓰지 말 것

DAC는 객체 소유자가 접근 권한을 설정할 수 있는 임의적 접근통제 방식이고, MAC는 보안 등급과 중앙 정책에 따라 접근을 강제로 통제하는 방식이다. RBAC는 역할에 권한을 부여하고 사용자를 역할에 배정하는 방식이며, ABAC는 사용자·자원·행위·환경 속성을 조합하여 접근 여부를 결정하는 방식이다.

DAC = 소유자
MAC = 보안등급·정책
RBAC = 역할
ABAC = 속성

MAC을 메시지 인증 코드와 혼동하지 말 것
접근통제의 MAC은 Mandatory Access Control

DAC: 객체 소유자가 권한 부여
MAC: 보안등급과 중앙 정책으로 강제 통제
RBAC: 역할에 권한을 묶고 사용자를 역할에 배정
ABAC: 사용자·자원·행위·환경 속성 조합으로 판단

DAC, MAC, RBAC, ABAC의 기준을 각각 소유자, 보안등급·정책, 역할, 속성으로 구분하면 기본점
MAC을 Mandatory Access Control로 명확히 쓰면 혼동 방지 가점
ABAC에서 환경 속성이나 행위 속성까지 포함하면 고득점

Bell-LaPadula 모델은 기밀성 보호를 목적으로 하며, 낮은 등급 주체가 높은 등급 객체를 읽지 못하게 하는 No Read Up과 높은 등급 주체가 낮은 등급 객체에 쓰지 못하게 하는 No Write Down 규칙을 사용한다. Biba 모델은 무결성 보호를 목적으로 하며, 높은 무결성 주체가 낮은 무결성 객체를 읽지 못하게 하는 No Read Down과 낮은 무결성 주체가 높은 무결성 객체에 쓰지 못하게 하는 No Write Up 규칙을 사용한다.

Bell-LaPadula = 기밀성
Biba = 무결성
No Read Up
No Write Down
No Read Down
No Write Up

기밀성과 무결성을 바꾸면 큰 감점
읽기·쓰기 방향도 주의

Clark-Wilson 모델은 상업적 시스템의 무결성을 보장하기 위한 모델로, 사용자가 데이터를 직접 수정하지 않고 승인된 프로그램과 잘 형성된 트랜잭션을 통해서만 데이터를 변경하도록 한다. 또한 직무분리와 감사 기능을 통해 부정행위와 오류를 방지한다.

상업적 무결성
잘 형성된 트랜잭션
승인된 프로그램
직무분리
감사

Bell-LaPadula처럼 No Read Up을 쓰지 말 것
Clark-Wilson은 트랜잭션, 직무분리, 감사가 핵심

위험관리는 자산을 식별하고 자산 가치를 평가한 뒤, 자산에 대한 위협과 취약점을 식별하여 위험의 가능성과 영향을 분석·평가하는 과정이다. 이후 위험 감소, 회피, 전가, 수용 중 적절한 처리 방법을 선택하고, 보호대책 적용 후 남는 잔여위험을 책임자의 승인 하에 지속적으로 관리해야 한다.

자산 식별
위협
취약점
위험 분석·평가
위험 처리
잔여위험

위협, 취약점, 위험을 같은 의미로 쓰지 말 것

자산 식별·가치 평가 → 위협·취약점 식별 → 가능성·영향 분석 → 위험 평가 → 위험 처리 → 잔여위험 승인·관리

자산, 위협, 취약점을 구분해 쓰면 기본점
가능성과 영향을 기준으로 위험을 분석·평가한다고 쓰면 핵심점
위험 처리와 잔여위험 승인·지속 관리를 포함하면 고득점

정성적 위험분석은 위험의 가능성과 영향을 높음, 중간, 낮음 등 등급으로 평가하는 방식으로 수행이 쉽지만 주관성이 개입될 수 있다. 정량적 위험분석은 자산 가치, 손실률, 발생빈도 등을 수치화하여 SLE와 ALE 같은 예상 손실액을 계산하는 방식으로 비용·효과 판단에 유용하지만 정확한 데이터 수집이 어렵다.

정성적 = 등급
정량적 = 수치·금액
SLE
ALE
주관성
데이터 수집

정성적과 정량적을 반대로 쓰지 말 것

위험 처리 방법에는 위험 감소, 회피, 전가, 수용이 있다. 위험 감소는 보안대책을 적용해 가능성이나 영향을 낮추는 것이고, 위험 회피는 위험한 활동을 중단하는 것이며, 위험 전가는 보험이나 외주 계약 등을 통해 손실 부담 일부를 이전하는 것이다. 위험 수용은 위험이 허용 수준 이내라고 판단하여 책임자의 승인 하에 받아들이는 방식이다.

감소
회피
전가
수용
보안대책
중단
보험·외주
승인

전가를 위험 제거라고 쓰지 말 것
전가는 손실 부담 일부 이전

정보보호 관리체계는 조직의 정보자산을 보호하기 위해 정보보호 정책, 조직, 자산관리, 위험관리, 보호대책, 교육, 점검, 개선 활동을 체계적으로 수립·운영하는 체계이다. 이를 통해 보안 위험을 줄이고 법규와 내부 정책을 준수하며, 침해사고 예방과 대응, 지속적인 보안 수준 개선을 수행할 수 있다.

정책
조직
자산관리
위험관리
보호대책
교육
점검
개선

기술 장비 도입만 쓰면 부족
관리체계는 지속적 운영 구조

정보보호 정책은 조직의 보안 목표와 원칙을 정한 최상위 문서이고, 지침은 정책을 구체화한 세부 기준이다. 절차는 실제 업무를 수행하는 순서와 방법을 정의한 문서이며, 기록은 정책과 절차에 따라 수행한 결과를 증명하는 증적이다.

정책 = 원칙
지침 = 기준
절차 = 방법
기록 = 증적

정책과 절차를 같은 의미로 쓰지 말 것

침해사고 대응은 사전 준비, 사고 탐지, 초기 대응, 원인과 피해 범위 분석, 피해 확산 차단, 악성 요소 제거, 서비스 복구, 보고와 신고, 사후 분석 및 재발 방지 순서로 수행한다. 각 단계에서 로그와 증거를 보존하고, 사고 대응 조직의 역할에 따라 신속하게 조치해야 한다.

준비
탐지
초기 대응
분석
차단
제거
복구
보고
재발 방지
증거 보존

복구만 쓰면 부족
보고, 재발 방지, 증거 보존을 포함

준비 → 탐지 → 초기 대응 → 분석 → 확산 차단 → 제거 → 복구 → 보고·신고 → 사후 분석·재발 방지

탐지, 분석, 차단, 제거, 복구의 흐름을 순서 있게 쓰면 기본점
증거 보존과 보고·신고를 포함하면 가점
사후 분석과 재발 방지 대책까지 쓰면 고득점

침해사고 증거는 원인 분석, 피해 범위 확인, 법적 대응, 재발 방지의 근거가 되므로 훼손되지 않도록 보존해야 한다. 로그, 메모리, 디스크 이미지, 악성 파일, 네트워크 패킷 등을 수집하고 해시값으로 무결성을 검증하며, 수집자·시간·인수인계 이력을 기록하여 증거 연계성을 유지해야 한다.

원본 보존
복제본 분석
해시값
무결성 검증
Chain of Custody
인수인계 이력

원본 파일을 직접 열어 수정하거나 분석한다고 쓰면 큰 감점
증거 보존을 단순 백업으로만 설명하고 무결성 검증을 누락하면 감점

원본 보존과 복제본 분석 원칙을 쓰면 기본점
수집 시 해시값을 계산하여 무결성을 검증한다고 쓰면 핵심점
수집자, 시간, 보관 위치, 인수인계 이력 등 Chain of Custody를 쓰면 고득점

BCP는 재해나 장애 상황에서도 조직의 핵심 업무를 지속하거나 신속히 복구하기 위한 전체 업무 관점의 계획이다. DRP는 BCP와 연계되는 IT 복구 계획으로, 서버, DB, 네트워크, 애플리케이션, 데이터 등 정보시스템의 복구 절차와 자원을 정의한다.

BCP = 업무연속성
DRP = IT 복구
핵심 업무
정보시스템

BCP와 DRP를 같은 개념으로 쓰지 말 것
BCP가 더 넓은 개념

BCP를 핵심 업무 지속 또는 업무연속성 계획으로 쓰면 기본점
DRP를 정보시스템 복구 절차와 자원 계획으로 쓰면 기본점
BCP가 DRP보다 넓은 업무 관점의 계획임을 비교하면 가점

RTO는 장애 발생 후 서비스를 얼마 안에 복구해야 하는지를 나타내는 복구 시간 목표이다. RPO는 장애 발생 시 어느 시점의 데이터까지 복구해야 하는지를 나타내는 복구 시점 목표로, RTO는 서비스 중단 시간과 관련되고 RPO는 허용 가능한 데이터 손실량과 관련된다.

RTO = 복구 시간
RPO = 복구 시점
서비스 중단 시간
데이터 손실량

RTO와 RPO를 반대로 쓰지 말 것

패치관리는 운영체제, 소프트웨어, 애플리케이션의 알려진 취약점과 오류를 보완하여 침해사고 가능성을 줄이기 위해 필요하다. 변경관리는 시스템 변경이 장애나 보안 문제를 유발하지 않도록 변경 요청, 영향 분석, 승인, 테스트, 적용, 검증, 이력 관리를 수행하는 절차이다.

패치 = 취약점 보완
변경 = 운영환경 변경 통제
영향 분석
승인
테스트
검증
이력 관리

패치관리와 변경관리를 같은 개념으로 쓰지 말 것

개인정보 안전성 확보조치는 개인정보의 분실, 도난, 유출, 위조, 변조, 훼손을 방지하기 위한 관리적·기술적·물리적 보호조치이다. 주요 대책으로 내부관리계획 수립, 접근권한 관리, 접근통제, 비밀번호와 중요정보 암호화, 접속기록 보관·점검, 악성프로그램 방지, 물리적 안전조치가 있다.

내부관리계획
접근권한 관리
접근통제
암호화
접속기록 보관·점검
악성프로그램 방지
물리적 안전조치

개인정보 보호 대책을 암호화 하나로만 설명하면 감점
접속기록 보관·점검을 누락하면 실무형 답안으로 약해짐

관리적·기술적·물리적 보호조치라는 성격을 쓰면 기본점
내부관리계획, 접근권한 관리, 접근통제, 암호화, 접속기록 보관·점검 중 4개 이상 쓰면 핵심점
악성프로그램 방지와 물리적 안전조치를 포함하면 가점

제3자 제공은 개인정보를 제공받는 자가 자신의 목적을 위해 개인정보를 이용하는 것이고, 업무위탁은 개인정보처리자의 업무를 수탁자가 대신 수행하는 것이다. 제3자 제공은 제공받는 자, 제공 목적, 제공 항목, 보유기간 등에 대한 동의 등 적법한 근거가 필요하고, 위탁은 위탁계약, 수탁자 공개, 교육·감독, 목적 외 이용 금지, 재위탁 통제가 필요하다.

제3자 제공 = 받는 자 목적
위탁 = 내 업무 대행
동의
위탁계약
수탁자 감독
재위탁 통제

둘을 같은 개념으로 쓰지 말 것
목적의 주체가 가장 중요

개인정보 유출 사고가 발생하면 유출 여부, 유출 항목, 정보주체 수, 유출 시점과 경위, 추가 유출 가능성, 암호화 여부, 피해 가능성을 확인해야 한다. 이후 추가 유출을 차단하고 증거를 보존하며, 정보주체 통지와 관계기관 신고 요건을 검토하고 피해 최소화 조치와 원인 제거, 재발 방지 대책을 수행해야 한다.

유출 여부
유출 항목
정보주체 수
추가 유출 차단
증거 보존
통지
신고
피해 최소화
재발 방지

통지·신고만 쓰고 원인 제거와 재발 방지를 누락하지 말 것

확인: 유출 여부, 항목, 정보주체 수, 시점, 경위, 추가 유출 가능성
초기 조치: 추가 유출 차단, 계정·세션 차단, 증거 보존
대외 조치: 정보주체 통지와 관계기관 신고 요건 검토
사후 조치: 원인 제거, 피해 최소화, 재발 방지

유출 범위 확인과 추가 유출 차단을 쓰면 기본점
증거 보존, 정보주체 통지, 관계기관 신고 검토를 포함하면 핵심점
원인 제거와 재발 방지 대책을 쓰면 고득점

ISMS는 조직의 정보보호 관리체계가 적절히 수립·운영되는지 인증하는 제도이다. ISMS-P는 정보보호 관리체계에 개인정보보호 관리체계를 포함한 인증제도로, 개인정보 수집, 이용, 제공, 보관, 파기, 정보주체 권리보장 등 개인정보 처리 단계별 보호조치를 포함한다.

ISMS = 정보보호 관리체계
ISMS-P = 정보보호 + 개인정보보호
개인정보 처리 단계
수집·이용·제공·파기

ISMS-P를 개인정보보호만으로 설명하지 말 것
정보보호와 개인정보보호의 통합 인증

1. 계정 관리 보안대책을 설명하시오.
2. 로그 관리의 필요성과 관리 방안을 설명하시오.
3. 패치관리 절차를 설명하시오.
4. 랜섬웨어 감염 시 대응 절차를 설명하시오.
5. ARP Spoofing의 개념과 대응 방안을 설명하시오.
6. SYN Flooding의 원리와 대응 방안을 설명하시오.
7. WAF와 일반 방화벽의 차이를 설명하시오.
8. SQL Injection의 개념과 대응 방안을 설명하시오.
9. XSS의 개념과 대응 방안을 설명하시오.
10. CSRF의 개념과 대응 방안을 설명하시오.
11. 파일 업로드 취약점의 위험과 대응 방안을 설명하시오.
12. IDOR 취약점의 개념과 대응 방안을 설명하시오.
13. 암호화와 해시의 차이를 설명하시오.
14. 전자서명의 개념과 제공하는 보안 속성을 설명하시오.
15. DAC, MAC, RBAC, ABAC의 차이를 설명하시오.
16. Bell-LaPadula 모델과 Biba 모델의 차이를 설명하시오.
17. 위험관리 절차를 설명하시오.
18. 침해사고 대응 절차를 설명하시오.
19. BCP와 DRP의 차이를 설명하시오.
20. 개인정보 안전성 확보조치를 설명하시오.

21. 최소권한 원칙
22. SetUID 위험
23. IDS와 IPS 차이
24. DNS Spoofing
25. Replay Attack
26. 쿠키 보안 속성
27. JWT 보안 주의사항
28. 비밀번호 솔트
29. PKI 구성요소
30. 위험 처리 방법 4가지
31. RTO와 RPO
32. 제3자 제공과 위탁
33. ISMS와 ISMS-P

정의가 정확한가?
위험 또는 필요성을 설명했는가?
핵심 대응책을 3개 이상 제시했는가?
운영·점검·증적·재발방지 관점을 포함했는가?
비교형 문제는 양쪽 차이를 기준으로 구분했는가?