이 노트에 대하여
세션 목록을 확인해봤는데, 지금 참조 가능한 다른 세션들은 문서 병합, 아침 브리핑, Word 서식 작업 등 보안과 무관한 내용이라 과거 대화 원문을 직접 끌어올 수는 없었다. 대신 지금까지 vault에 쌓인 보안 관련 노트(위험관리, 시큐어 엔지니어링, AWS 클라우드 보안, 모바일 앱 진단, 웹 정찰 방법론, CTF)를 하나의 흐름으로 엮어 정리했다. 각 항목 아래 원본 상세 노트 링크를 달아뒀으니 필요할 때 파고들면 된다.
1. 보안의 출발점 — 위험관리(Risk Management)
모든 보안 활동의 공통 언어.
Risk = Probability × Impact
| 개념 | 정의 |
|---|---|
| Asset | 반드시 보호해야 하는 핵심 인프라·지적재산·데이터 |
| Threat | 취약점을 악용해 자산을 손상·유출시킬 수 있는 의도적/우발적 요인 |
| Vulnerability | 위협에 악용될 수 있는 시스템·애플리케이션의 결함 |
| Risk | 위협이 취약점을 성공적으로 악용했을 때의 정량적 발생가능성 × 영향 |
면접/실무 감각
이 4개념은 이후 나오는 모든 보안 통제(접근제어, 암호화, 모니터링)를 “왜 하는가”로 설명할 때 쓰는 기본 문법이다. 어떤 통제를 제안하든 “이 자산에, 이 위협을, 이 취약점을 통해 막는다”로 환원해서 말할 수 있어야 한다.
원본: Risk
2. Secure Engineering — 신뢰할 수 있는 시스템을 만드는 법
Assurance 4단계
개발 각 단계에서 “증거 사슬(chain of evidence)“을 남겨 신뢰성을 증명하는 개념.
| 단계 | 질문 |
|---|---|
| Policy assurance | 요구사항 도출이 제대로 되었는가? |
| Design assurance | 요구사항대로 설계가 되었는가? |
| Implementation assurance | 설계대로 구현이 되었는가? |
| Operational assurance | 운영 중에도 요구사항이 계속 유지되는가? |
Secure by Design 8원칙
| 원칙 | 의미 |
|---|---|
| Least privilege | 최소 권한의 법칙 |
| Fail-safe default | 명시적으로 허락된 것이 아니면 거부, 문제 시 안전했던 상태로 복귀 |
| Economy of mechanism | 최대한 단순하게 설계 |
| Complete mediation | 모든 접근 시도를 예외 없이 감시·통제 |
| Open design | 설계를 공개해 대중의 검증을 받음 (보안을 은닉에 의존하지 않음) |
| Separation of privilege | 중요 권한은 분리해서 운영·관리 |
| Least common mechanism | 공유 요소를 최소화해 한 곳의 문제가 전체로 번지지 않게 함 |
| Psychological acceptability | 아무리 안전해도 쓰기 불편하면 안 쓴다 — 사용성도 보안 요소 |
왜 이걸 알아야 하나
이 8원칙은 AWS IAM 최소권한 설계, 프롬프트 인젝션 방어의 최소권한 원칙, 네트워크 세그멘테이션까지 — 이후 배우는 거의 모든 구체적 보안 기술의 이론적 뿌리다. “왜 최소권한을 줘야 하나요?”에 대한 답이 바로 이 원칙들.
원본: Secure Engineering_01, Secure Engineering_02
3. 클라우드 보안 — AWS 핵심 판별 기준
AWS SCS-C03(보안 전문분야) 학습 과정에서 정리한 실무 판별 공식들.
IAM 정책 문법
- 평가 순서: Explicit Deny > Allow > Implicit Deny(기본 거부)
Deny + StringNotEquals= 화이트리스트(나열된 값만 통과),Allow + StringEquals= 나열된 값만 허용BoolIfExists/StringNotEquals류는 키가 없어도 매치되어 Deny가 발동하는 함정이 잦음NotAction은 “안 한다”가 아니라 “제외한 나머지 전부”라는 뜻
서비스 역할 구분 (자주 헷갈리는 지점)
| 질문 | 서비스 |
|---|---|
| 누가 무엇을 했나 | CloudTrail |
| 지금 어떤 상태인가 / 규정 준수 | Config |
| 성능·수치가 임계값을 넘었나 | CloudWatch |
| 취약점(CVE) 스캔 (배포 전) | Inspector |
| 위협 탐지 (런타임) | GuardDuty |
| findings 집계·규정 준수 점검 | Security Hub (스스로 탐지하지 않음) |
| 사후 근본원인 조사 | Detective (탐지가 아니라 조사) |
| S3 민감데이터 탐지 | Macie |
KMS·S3 데이터 보호
- 봉투 암호화:
GenerateDataKey→ 평문 키로 로컬 암호화 후 즉시 폐기, 마스터 키는 HSM 밖으로 절대 안 나옴 - S3 삭제 방지 계층: 버전관리(실수 복구용) < MFA Delete < Object Lock Governance(권한자 우회 가능) < Object Lock Compliance(누구도 불가)
범용 판별 원칙
- 클라이언트 측 검증 선지는 항상 오답 (공격자 통제 영역이라 신뢰 불가)
- 이미 허용된 권한을 또 주는 선지는 함정
- “가장 운영 효율적” = 관리형 서비스가 정답 후보
- 배스천 호스트는 레거시 취급 (Session Manager가 대개 정답)
원본: AWS-DAY1 (문제풀이형), summary (암기 포인트형)
4. 모바일 앱 보안 진단 — 인증서 피닝 우회
Burp Suite로 안드로이드 앱 트래픽을 캡처하기 위한 시스템 인증서 설치 절차.
공통 흐름: 개인키 생성 → DER 변환 → PKCS8 변환 → Burp에 import → 기기로 push → 시스템 파티션에 마운트
| 구분 | Android 14 미만 | Android 14 이상 |
|---|---|---|
| 인증서 저장 경로 | /system/etc/security/cacerts/ | /apex/com.android.conscrypt/cacerts |
| remount 가능 여부 | 가능 | 불가능 (root여도 직접 수정 불가) |
| 대응 방식 | 해시된 .0 파일을 바로 시스템 파티션에 복사 | tmpfs로 새 마운트를 만들어 기존 인증서 복사 + 신규 인증서 추가 후 Zygote/실행 중 앱까지 마운트 네임스페이스에 주입 |
실무 포인트
Android 14부터는 OS 자체가 시스템 인증서 신뢰 저장소를 앱별 네임스페이스로 격리해버려서, 예전 방식(직접 파일 교체) 그대로는 안 통한다. “OS 버전이 바뀌면 우회 기법도 재검증해야 한다”는 걸 보여주는 대표 사례.
원본: AOS 인증서 세팅 (14 미만), AOS 인증서 세팅 (14 이상)
5. 웹/네트워크 정찰(Recon) 방법론
침투테스트·CTF의 첫 단계인 표면 탐색 3종 구분.
| 개념 | 정의 | 언제 찾는가 |
|---|---|---|
| Subdomain | 메인 도메인 앞에 붙는 하위 도메인 | DNS가 살아있는 퍼블릭 도메인일 때 |
| Directory | 웹 서버 URL 경로 | 웹 서버 접근 가능하면 항상 (가장 기본) |
| vHost | 같은 IP에서 도메인명으로 구분되는 가상 호스트 | /etc/hosts 등록형 환경, DNS로 안 열리는 서브도메인 발견 시 |
핵심 도구는 ffuf/gobuster이며, 워드리스트는 목적(빠른 스캔 vs 정밀 스캔)에 따라 dirb/common.txt → dirbuster/directory-list-2.3-medium.txt → seclists류로 단계적으로 키운다.
원본: subdomain, directory, vHost
6. 실전 트레이닝 — CTF/HTB
정찰 방법론을 실제로 적용해본 HTB 박스 목록 (Basqueda, Build, Builder, Cap, Certified, Escape, Kobold, Servmon 등). OSCP 대비 명령어 모음도 함께 정리되어 있다.
원본: CTF
7. 도구 활용 — Terminator
여러 도구(nmap, dirbuster 등)를 동시에 돌리기 위한 터미널 분할 단축키 모음 (Ctrl+Shift+E 세로분할, Ctrl+Shift+O 가로분할, Ctrl+Shift+X 전체화면 토글 등).
원본: terminator
학습 궤적으로 보면
정리하고 보니 커버 범위가 이론(위험관리, 시큐어 엔지니어링) → 클라우드 디펜시브(AWS 보안 자격증) → 오펜시브 실습(모바일 인증서 우회, 웹 정찰, HTB) → 최근 AI 보안까지 확장되는 흐름이다. 방어자 관점과 공격자 관점을 둘 다 쌓고 있다는 게 다른 지원자 대비 차별점으로 말하기 좋은 지점.