· 생활·도구 가이드

AP21 — 주요 공격 기법과 계층형 방어

응용정보기술자시험 과목 A에 필요한 SQL 인젝션·XSS·CSRF 구분, 피싱·랜섬웨어·DoS/DDoS 대응 계층, 방화벽·WAF·IDS·IPS의 역할과 한계를 판단 예제 2개와 오리지널 연습 문제 5문항으로 익힙니다.

応用情報技術者試験科目A情報セキュリティ攻撃手法多層防御

AP 과목 A 제21편 · 2026년도·실라버스 Ver.7.2 기준의 독립 학습 자료입니다. IPA와 제휴하지 않으며 합격을 보장하지 않습니다. 시리즈 허브 보기

오리지널 학습 자료 · 기준: AP 과목 A(2026), IPA 실라버스 Ver.7.2 · 수정/출처 확인: 2026-10-21

개정 이력: 2026-10-28 인시던트 관리 수명주기의 참조 회차를 AP22에서 AP25로 바로잡음.

학습 인덱스

이 글을 마치면 다음을 할 수 있어야 한다.

  1. SQL 인젝션, XSS, CSRF를 원인 → 영향 → 주 방어 → 보조 통제의 한계로 구분한다.
  2. 피싱, 랜섬웨어, DoS/DDoS에 단일 제품이 아닌 예방·탐지·대응·복구 계층을 고른다.
  3. 방화벽, WAF, IDS, IPS의 관찰 지점과 동작 차이를 설명한다.
  4. 짧은 사례에서 가장 직접적인 통제를 선택한다.

IPA Ver.7.2의 정확한 위치

아래의 앞 숫자는 PDF 페이지, 뒤 숫자는 문서에 인쇄된 푸터 페이지다.

PDF/푸터 대분류 → 중분류 → 항목 이 글의 연결점
53/49 대분류 3 기술 요소 → 중분류 11 보안 → 1. 정보 보안 → (3) 위협 → ② 멀웨어·악성 프로그램 랜섬웨어
54/50 같은 계층 → 1. 정보 보안 → (7) 공격 수법 XSS, CSRF, SQL 인젝션, 피싱, DoS/DDoS, 표적형 공격 등
57/53 대분류 3 기술 요소 → 중분류 11 보안 → 2. 정보 보안 관리 → (6) 인시던트 관리 탐지·접수, 분류, 대응, 보고·공개
59/55 대분류 3 기술 요소 → 중분류 11 보안 → 4. 정보 보안 대책 → (1) 종류 → ② 기술적 대책 3-2-1/WORM/불변 백업, 권한, 로그, 패치, 감시, FW/WAF/IDS/IPS/EDR/SIEM
60/56 같은 중분류 → 5. 보안 구현 기술 → (4) 네트워크 보안, (5) 데이터베이스 보안, (6) 애플리케이션 보안 시작 필터링, 리버스 프록시, DB 접근·백업·로그, 안전한 프로그래밍·취약점 시험
61/57 같은 계층 → 5. 보안 구현 기술 → (6) 애플리케이션 보안 계속 XSS 대책, 플레이스홀더를 포함한 SQL 인젝션 대책

AP19의 암호·인증서와 AP20의 인증·접근통제 기초는 여기서 다시 설명하지 않는다. 최소 권한은 공격의 피해 범위를 줄이는 한 계층으로만 사용한다. 인시던트 관리의 전체 수명주기는 AP25 범위이며, 여기서는 탐지→대응→복구 연결만 다룬다.

공통 용어표

English 한국어 日本語
SQL injection SQL 인젝션 SQLインジェクション
Cross-site scripting (XSS) 크로스 사이트 스크립팅(XSS) クロスサイトスクリプティング（XSS）
Cross-site request forgery (CSRF) 크로스 사이트 요청 위조(CSRF) クロスサイトリクエストフォージェリ（CSRF）
Phishing 피싱 フィッシング
Ransomware 랜섬웨어 ランサムウェア
Denial of service (DoS/DDoS) 서비스 거부 공격(DoS/DDoS) サービス妨害攻撃（DoS/DDoS）
Firewall 방화벽 ファイアウォール
Web application firewall (WAF) 웹 애플리케이션 방화벽(WAF) Webアプリケーションファイアウォール（WAF）
Intrusion detection system (IDS) 침입 탐지 시스템(IDS) 侵入検知システム（IDS）
Intrusion prevention system (IPS) 침입 방지 시스템(IPS) 侵入防止システム（IPS）
Defense in depth 심층 방어 多層防御
Immutable backup 불변 백업 イミュータブルバックアップ

1. 웹 공격 세 가지를 원인부터 구분하기

SQL 인젝션

  • 근본 원인: 신뢰할 수 없는 데이터가 SQL 명령의 구조 일부로 결합된다.
  • 영향: 의도하지 않은 조회·변경·삭제, 인증 우회, 정보 노출 등이 생길 수 있다.
  • 주 설계 방어: 값은 파라미터화된 쿼리/준비된 문장/플레이스홀더로 바인딩해 코드와 데이터를 분리한다. 테이블명·정렬 방향처럼 바인딩할 수 없는 동적 식별자는 필요한 후보만 허용 목록으로 선택한다. DB 계정에는 최소 권한을 준다.
  • 보조 통제의 한계: 입력 검증, 로깅, WAF는 탐지와 완화에 도움을 주지만 취약한 쿼리 조립을 고치지 않는다. 수동 이스케이프는 문맥·DB 설정에 따라 틀리기 쉬우므로 주 대책이 아니다.

XSS

  • 근본 원인: 신뢰할 수 없는 데이터가 브라우저에서 실행 가능한 HTML/스크립트 문맥으로 해석된다.
  • 영향: 표시 내용 변조, 사용자 세션에서의 의도하지 않은 동작, 민감 정보 노출 등이 가능하다.
  • 주 설계 방어: 출력 위치(HTML 본문, 속성, URL, JavaScript 등)에 맞는 문맥별 출력 인코딩을 사용하고, 텍스트 전용 DOM API나 자동 이스케이프 템플릿 같은 안전한 싱크를 쓴다. 허용 형식이 명확한 입력은 함께 검증한다.
  • 보조 통제의 한계: CSP와 WAF는 심층 방어지만 안전한 출력 처리를 대신하지 않는다. 한 문맥의 인코딩을 다른 문맥에 그대로 적용해서도 안 된다.

CSRF

  • 근본 원인: 로그인 세션을 가진 브라우저가 공격자가 유도한 원치 않는 상태 변경 요청을 정상 자격 증명과 함께 보낸다.
  • 영향: 사용자의 의도와 다른 설정 변경, 전송, 등록·삭제 등이 수행될 수 있다.
  • 주 설계 방어: 프레임워크의 CSRF 보호 또는 예측 불가능하고 서버가 검증하는 anti-CSRF 토큰을 사용한다. 적절한 SameSite 쿠키와 Origin/Referer 검증을 추가 계층으로 적용한다. GET은 상태를 변경하지 않도록 설계한다.
  • 보조 통제의 한계: XSS용 출력 인코딩은 CSRF의 주 해결책이 아니다. CORS만으로도 부족하다. 또한 XSS가 존재하면 일부 CSRF 방어가 우회될 수 있으므로 둘 다 고쳐야 한다.

기억법: SQLi는 서버 쿼리 구조, XSS는 브라우저 출력 문맥, CSRF는 인증된 브라우저가 보낸 요청의 의도를 보호한다.

2. 사람·단말·서비스를 노리는 공격과 계층

피싱

합성 사례: 직원에게 “거래처 계좌가 바뀌었다”는 메시지가 온다. 링크를 바로 열거나 송금하지 않고, 저장된 공식 연락처로 별도 확인한다. 조직은 사용자 훈련·신고 채널, 메일/웹 필터링, 최소 권한, 단말 감시, 중앙 로그와 인시던트 처리를 겹친다. 훈련만으로 모든 기만을 막는다고 보지 않는다.

랜섬웨어

합성 사례: 한 단말에서 파일의 비정상 대량 변경 경보가 발생한다. 팀은 절차에 따라 단말을 격리하고 범위를 확인하며, 보호된 중앙 로그로 시간대를 조사하고, 깨끗함을 확인한 환경에 시험된 오프라인/불변 백업을 복구한다.

  • 패치 적용은 알려진 취약점 경로를 줄이지만 피싱, 잘못된 설정, 미지 취약점 등 모든 침입 경로를 막지는 못한다.
  • 최소 권한과 네트워크 분할은 이동과 피해 반경을 제한한다.
  • 3-2-1 원칙, WORM 또는 불변 저장소, 복구 시험은 복구 가능성을 높인다. 백업은 감염이나 데이터 탈취를 예방하지 않는다. 온라인으로 늘 연결된 백업은 함께 손상될 수 있다.
  • 로그는 수집되고, 변조로부터 보호되고, 실제로 검토될 때 탐지·조사에 도움이 된다. 로그 자체가 공격을 차단하지는 않는다.

DoS/DDoS

합성 사례: 공개 서비스에 여러 출처에서 트래픽이 급증해 정상 사용자가 지연을 겪는다. 단일 서버 방화벽만으로 상류 회선을 이미 포화시킨 트래픽을 해결하기 어렵다. 제공자와 준비한 상류 DDoS 완화, CDN/애니캐스트 분산, 적절한 레이트 제한, 캐시·용량 설계, 모니터링과 대응 절차를 조합한다. 레이트 제한은 정상 급증도 막을 수 있고, 용량 증설만으로 모든 공격을 흡수할 수 없으므로 기준선과 시험이 필요하다.

3. 방화벽·WAF·IDS·IPS 비교

통제 주 관찰/동작 강점 한계·주의
방화벽 네트워크/전송 계층의 주소·포트·연결 상태 정책 불필요한 연결 경로 축소 애플리케이션 코드를 고치지 못하며, 허용된 트래픽 안의 해로운 의미를 못 볼 수 있음
WAF HTTP 애플리케이션 요청 검사·차단 웹 요청에 대한 보상적 차단 계층 오탐·미탐이 있고 안전한 코딩의 대체물이 아님
IDS 관찰 후 탐지·경보 가시성과 조사 단서 제공 일반적으로 자동 차단하지 않으며 경보 검토 필요
IPS 인라인 탐지·차단 알려진/정책 위반 트래픽을 즉시 막을 수 있음 튜닝이 필요하고 오탐, 성능, 가용성 영향 가능

어느 제품도 만능이 아니다. 암호화된 트래픽, 이미 허용된 흐름, 센서 위치 때문에 보이는 범위가 달라진다. 따라서 안전한 설계·패치·권한·분할·감시·복구를 계층화한다.

4. 안전한 의사결정 예제

예제 A — 웹 요청/데이터 흐름

검색 API가 사용자의 검색어와 정렬 항목을 받아 DB를 조회하고 결과를 HTML에 표시한다.

  1. 검색어 값은 준비된 문장의 플레이스홀더에 바인딩한다.
  2. 정렬 열과 방향은 서버가 정의한 허용 목록에서만 고른다.
  3. 결과는 표시되는 문맥에 맞게 출력 인코딩하고 안전한 템플릿/싱크를 쓴다.
  4. DB 계정은 필요한 읽기 권한만 가진다.
  5. WAF와 보호된 로그는 추가 탐지·완화 계층으로 둔다.

이 선택은 SQLi와 XSS의 주 원인을 각각 코드에서 제거하고, 최소 권한과 WAF로 남은 위험을 제한한다.

예제 B — 탐지에서 복구까지

직원이 의심스러운 첨부파일을 신고한 직후 한 단말에서 비정상 변경 경보가 발생했다.

  1. 신고와 경보를 접수·분류하고, 승인된 절차로 영향 단말을 격리한다.
  2. 보호된 중앙 로그로 계정·단말·구간의 범위를 조사한다.
  3. 노출된 자격 증명과 취약 경로를 처리하고, 분할·최소 권한이 확산을 제한했는지 확인한다.
  4. 깨끗한 환경을 확인한 뒤 시험된 오프라인/불변 백업에서 복구하고 정상성을 검증한다.
  5. 필요한 보고와 개선은 조직 절차로 넘긴다.

백업만 먼저 덮어쓰면 침입 원인이 남을 수 있고 증거를 잃을 수 있다. 상세 인시던트 수명주기는 AP25에서 다룬다.

5. 오리지널 4지선다 문제

모든 문제는 이 자료를 위해 만든 안전한 개념 사례이며 IPA 기출문제가 아니다.

문제 1

웹 애플리케이션이 문자열 연결로 SQL을 만들고 있다. 가장 직접적인 주 대책은?

  • ア. DB 서버 앞에 IDS만 설치한다.
  • イ. 값은 준비된 문장의 플레이스홀더로 바인딩하고 동적 식별자는 허용 목록으로 고른다.
  • ウ. 오류 메시지만 숨긴다.
  • エ. 모든 입력을 개발자가 수동으로 이스케이프한다.

정답: イ (2)

  • ア: 탐지 단서는 되지만 취약한 쿼리 구조를 고치지 않는다.
  • イ: 코드와 데이터를 분리하므로 주 원인을 직접 해결한다.
  • ウ: 정보 노출을 줄일 수 있으나 인젝션은 남는다.
  • エ: 문맥과 DB 설정에 따라 실패하기 쉬워 주 대책이 아니다.

문제 2

로그인 사용자가 공격자 페이지를 연 뒤 의도하지 않은 주소 변경 요청이 전송됐다. 가장 알맞은 설명과 대책은?

  • ア. XSS이므로 HTML 출력 인코딩만 한다.
  • イ. SQL 인젝션이므로 DB 권한만 줄인다.
  • ウ. CORS 설정만 하면 모든 경우 해결된다.
  • エ. CSRF이므로 검증되는 anti-CSRF 토큰과 적절한 SameSite/Origin 검사를 적용한다.

정답: エ (4)

  • ア: 이 사례의 핵심은 출력 실행이 아니라 인증된 브라우저의 원치 않는 요청이다.
  • イ: SQL 구조 변경 사례가 아니다.
  • ウ: CORS만은 CSRF의 주 방어가 아니다.
  • エ: 원인에 맞는 주 방어와 추가 계층이다.

문제 3

직원이 계좌 변경 메시지를 받고, 동시에 단말에서 의심스러운 파일 변경 경보가 발생했다. 가장 적절한 조합은?

  • ア. 공식 연락처로 별도 확인하고 신고하며, 절차에 따라 격리·조사한 뒤 깨끗한 환경에 시험된 오프라인/불변 백업을 복구한다.
  • イ. 백업이 있으므로 단말 조사는 생략한다.
  • ウ. 패치가 최신이면 피싱은 불가능하다고 본다.
  • エ. 로그를 보존하지 않고 즉시 모든 시스템을 초기화한다.

정답: ア (1)

  • ア: 사람 확인, 탐지, 대응, 복구를 계층화한다.
  • イ: 백업은 감염·탈취를 막지 않으며 원인이 남을 수 있다.
  • ウ: 패치는 모든 공격 경로를 막지 않는다.
  • エ: 범위 판단과 조사 단서를 잃고 과도한 중단을 만들 수 있다.

문제 4

분산된 출처의 대량 트래픽이 인터넷 회선을 포화시킨다. 가장 적절한 준비는?

  • ア. 사내 IDS 경보만 늘린다.
  • イ. 애플리케이션의 출력 인코딩만 강화한다.
  • ウ. 상류 DDoS 완화와 CDN/애니캐스트, 적절한 레이트 제한·용량·모니터링을 조합한다.
  • エ. DB 계정 권한만 줄인다.

정답: ウ (3)

  • ア: 탐지만으로 포화된 상류 링크를 복구하지 못한다.
  • イ: XSS 대책이며 가용성 공격의 직접 대책이 아니다.
  • ウ: 공격이 서비스에 도달하기 전과 도달한 뒤의 계층을 함께 둔다.
  • エ: 피해 제한에는 유용할 수 있으나 회선 포화를 해결하지 않는다.

문제 5

방화벽, WAF, IDS, IPS에 대한 설명으로 가장 적절한 것은?

  • ア. 방화벽은 허용된 HTTP 내부 의미까지 항상 완전히 이해한다.
  • イ. IDS는 주로 탐지·경보하고, IPS는 인라인 차단할 수 있으며, WAF는 HTTP 계층의 보상 통제이므로 모두 튜닝과 계층화가 필요하다.
  • ウ. WAF를 두면 취약한 애플리케이션 코드를 고칠 필요가 없다.
  • エ. IPS는 오탐이나 가용성 영향을 일으키지 않는다.

정답: イ (2)

  • ア: 방화벽의 가시성은 정책, 암호화, 위치에 제한된다.
  • イ: 역할과 한계를 모두 올바르게 설명한다.
  • ウ: WAF는 안전한 코딩의 대체물이 아니다.
  • エ: 인라인 차단은 튜닝 실패 시 정상 트래픽과 성능에 영향을 줄 수 있다.

정답표: 1–5 = [2, 4, 1, 3, 2] = [イ, エ, ア, ウ, イ]

퀵 시트

  • SQLi: 쿼리 구조 분리 → 파라미터/플레이스홀더, 동적 식별자 허용 목록.
  • XSS: 브라우저 문맥 분리 → 문맥별 출력 인코딩, 안전한 싱크.
  • CSRF: 요청 의도 검증 → 프레임워크 보호/토큰 + SameSite/Origin 계층.
  • 백업은 복구, 최소 권한·분할은 피해 반경 제한, 로그는 탐지·조사.
  • 방화벽=연결 정책, WAF=HTTP 검사, IDS=경보, IPS=인라인 차단.
  • 단일 통제는 만능이 아니다. 예방·탐지·대응·복구를 겹친다.

셀프 체크

  • SQLi, XSS, CSRF의 보호 대상을 한 문장씩 말할 수 있다.
  • 백업·패치·최소 권한·로그가 “못 하는 일”도 설명할 수 있다.
  • 방화벽/WAF/IDS/IPS의 차이와 오탐·가시성 한계를 비교할 수 있다.
  • 두 의사결정 예제를 답을 보지 않고 재구성할 수 있다.
  • 다섯 문제의 오답이 왜 틀렸는지 설명할 수 있다.

공식 출처

2026-10-21 확인: IPA 실라버스 Ver.7.2, OWASP의 SQL 인젝션·XSS·CSRF 예방 자료, CISA의 StopRansomware·DDoS 대응, NIST SP 800-61 Rev.3·SP 800-41 Rev.1·SP 800-94.

1·3·7일 복습

  • 1일 후: 퀵 시트를 가리고 세 웹 공격의 원인과 주 방어를 써 본다.
  • 3일 후: 두 사례에 통제를 다시 배치하고 각 통제의 한계를 한 줄씩 붙인다.
  • 7일 후: 다섯 문제를 다시 풀고, 틀린 선택지를 올바른 문장으로 고친다.

이 자료는 IPA와의 제휴·승인을 주장하지 않으며 합격을 보장하지 않는다.

블로그로