푸른영혼의별

보안 설계를 하다 보면 결국 기본 개념을 얼마나 정확히 이해하고 있는가로 귀결됩니다.
공격 유형, 인증 요소, 암호 알고리즘은 모든 보안 논의의 출발점입니다.
아래는 실무와 시험 모두에서 자주 등장하는 핵심 개념 정리입니다.

1. 공격 유형: 소극적 공격 vs 적극적 공격

보안 공격은 시스템에 변화를 주는지 여부에 따라 구분됩니다.

• 소극적 공격 (Passive Attack)
  • 목적: 정보 수집
  • 특징: 시스템 자원이나 데이터에 직접적인 변경 없음
  • 예시: 도청(Eavesdropping)
    → 네트워크 트래픽을 몰래 감청하여 정보를 획득
• 적극적 공격 (Active Attack)
  • 목적: 시스템 교란 또는 정보 조작
  • 특징: 데이터나 시스템 상태를 의도적으로 변경
  • 예시: 위·변조(Tampering)
    → 전송 중인 데이터 내용을 수정하거나 삽입

👉 핵심 차이:
“읽기만 하느냐(소극)” vs “건드리느냐(적극)”

2. 인증 요소의 3가지 분류

인증(Authentication)은 사용자가 누구인지 증명하는 과정이며, 다음 세 가지 요소로 나뉩니다.

• 지식 기반 인증 (Something You Know)
  • 사용자가 알고 있는 정보
  • 예시: 비밀번호(Password)
• 소유 기반 인증 (Something You Have)
  • 사용자가 소유한 물리적/논리적 수단
  • 예시: OTP 토큰
• 행동 기반 인증 (Something You Do / Are)
  • 사용자의 행동 특성 또는 생체 특징
  • 예시: 서명(Signature)

👉 실무에서는 보안을 강화하기 위해
**2가지 이상을 조합한 다중 인증(MFA)**을 사용합니다.

3. KISA에서 개발한 대칭키 블록 암호 알고리즘

국내 표준 암호 알고리즘 중 하나로,
한국인터넷진흥원(KISA)에서 개발한 대칭키 블록 암호는 다음과 같습니다.

• SEED
  • 블록 크기: 128비트
  • 키 길이: 128비트
  • 특징: 국내 공공기관 및 금융권에서 널리 사용

SEED는 AES 이전에 국내 표준으로 채택되었으며,
현재도 레거시 시스템과 공공 프로젝트에서 자주 등장합니다.

마무리

보안은 고급 기술보다 기본 개념의 정확성이 먼저입니다.

• 공격은 소극/적극으로 구분하고
• 인증은 지식·소유·행동으로 나누며
• 국내 블록 암호 알고리즘으로는 SEED를 기억하면 됩니다.

이 세 가지만 정확히 알고 있어도
보안 설계, 면접, 시험에서 최소한의 신뢰선은 확보됩니다.

1️⃣ 사고는 “미설정”이 아니라 “방치”에서 난다

실제 사고 패턴은 거의 이렇습니다.

• 초기에는 설정돼 있었음
• 담당자 변경
• 프로젝트 종료
• 예외 처리 추가
• 긴급 대응 후 원복 안 됨

👉 보안은 꺼진 게 아니라 ‘잊힌 상태’에서 터집니다.

2️⃣ 보안 설정의 수명은 사람보다 짧다

• 계정 만료 ❌
• 방화벽 규칙 누적
• 임시 포트 상시화
• 테스트용 계정 운영 반영
• 로그 적재 중단

이 중 의도적으로 취약하게 만든 건 거의 없음
대부분은 “나중에 정리하자”입니다.

3️⃣ 그래서 보안은 설정 문제가 아니라 운영 문제

보안이 무너지는 순간은 이때입니다.

• 누가 책임자인지 모를 때
• 왜 이 설정이 있는지 모를 때
• 언제 제거해야 하는지 모를 때

즉,

보안 설정은 기술이 아니라
책임과 시간의 문제다

4️⃣ 살아있는 보안의 최소 조건

✔ 보안은 상태가 아니라 프로세스여야 한다

• 정기 점검 주기
• 변경 이력
• 예외 만료일

✔ “왜 열려 있는지” 설명 가능해야 한다

• 설명 못 하면 취약점

✔ 자동화보다 중요한 건 가시성

• 다 열려 있으면 아무도 안 본다
• “이상”이 보이게 만드는 게 핵심

5️⃣ 현업용 한 줄 번역

• “보안 다 돼 있습니다” ❌
• “이 설정을 누가, 언제, 왜 유지하고 있는지 설명 가능합니다” ⭕

한 줄 결론

보안은 켜는 기술이 아니라
잊지 않게 만드는 구조다.

위험은 기술보다 가정에서 시작됩니다.

원문

가장 위험한 취약점은 ‘설마’라는 가정이다

업무용 정제 버전

• 최대 취약점은 ‘설마 그럴 리 없다’는 전제다.
• 사고는 버그보다 가정에서 먼저 발생한다.
• 보안 사고의 시작점은 기술 결함이 아니라 낙관적 가정이다.

운영 관점 한 줄

• 설계는 설마를 제거하는 일
• 대응은 이미 터졌다를 전제로 준비하는 일

설마를 가정하는 순간, 사고는 일정에 들어간다.

업무용 정제 버전

• 완벽한 예방은 불가능하다. 차이는 탐지 시간과 복구 시간이다.
• 보안의 성과는 차단율이 아니라 MTTR과 Dwell Time이다.
• 사고는 발생한다. 비용을 결정하는 건 발견과 복구의 속도다.

운영 관점 요약

• 예방: 기본값(필수)
• 핵심 KPI: 탐지 시간 ↓ / 복구 시간 ↓
• 설계 원칙: 단순화 · 롤백 가능 · 자동 복구

한 줄 확장

보안은 ‘뚫릴 수 있느냐’가 아니라 ‘얼마나 빨리 정상으로 돌아오느냐’의 문제다.

보안은 옵션도, 부가 기능도 아닙니다. 기본값(default)입니다.

업무 관점에서 풀면 이렇게 정리됩니다.

• 설계 단계: 인증·권한·암호화·로깅은 요구사항이 아니라 전제조건
• 개발 단계: 보안 미구현 = 기능 미완성
• 운영 단계: 사고 대응 비용은 예방 비용의 수십 배
• 조직 관점: 보안 부채는 기술 부채가 아니라 법·재무 리스크

한 줄로 말하면

“보안을 나중에 붙인 시스템은 이미 실패한 설계다.”

특히 공공·SI 쪽에서는 더 냉정합니다.
보안 결함은 버그가 아니라 감사 지적 + 계약 리스크 + 개인 책임으로 돌아옵니다.

웹 서버에 다음과 같은 로그를 발견하였다. 어떤 공격으로 판단할 수 있는가? "GET /login.php?id%3D%27user%27%20and%20pw%3D%271%27%20or%201%3D1HTTP/1.1" 200 3926

/login.php?id='user' and pw='1' or 1=1
이건 전형적인 SQL Injection 공격입니다.
구체적으로는 인증 우회 목적의 SQL Injection입니다.

판단 근거
or 1=1
→ 조건을 항상 참으로 만들어 로그인 검증을 무력화하는 대표적인 패턴

id='user' and pw='1' or 1=1
→ 비밀번호가 틀려도 WHERE 절 전체가 참이 되도록 유도

URL 인코딩(%3D, %27, %20)
→ 웹 요청에서 SQL 구문을 숨기기 위한 일반적인 공격 기법