Q22. SASE는 통합 보안 플랫폼인가요?

A. SASE는 통합 보안이 아닙니다.
SASE는 접근 경로(Edge)를 통합한 것이지,
침해 행위(Host/App)를 끝까지 관찰·대응하는 플랫폼이 아닙니다.

※ SASE(Secure Access Service Edge)는
네트워크(SD-WAN)와 보안 기...

더 읽기

Q20. 서명키 하드코딩은 문제의 본질일까요?

A. 그렇지 않습니다. 하드 코딩은 ‘문제의 형태’일 수는 있지만, 문제의 본질은 아닙니다.

이번 쿠팡 인증키 노출 사례 이후, 많은 해석이 하나의 문장으로 요약되었습니다.

“서명키를 하드 코딩해서 사고가 났다.”

그러나 이 문장은 사건을 설명하기에는 너무 단순하...

더 읽기

Q21. 퇴사한 개발자가 서명키를 반출해 공격자로 변한다면 어떻게 대응할까요?

A. 전제를 바꿔야 합니다.
“반출되지 않았을 것”이 아니라,
“이미 반출되었을 수 있다”에서 출발해야 합니다.

Q20에서 논의했듯이,
쿠팡의 서명키 사고의 본질은 하드 코딩이 아니라
교체를 전제로 하지 않은 설계와 운영이었습니다.

이 전제는
개발자 퇴사 시점에서 더 ...

더 읽기

Q01. 요청본문(Post-body)·응답본문(Response-body) 로그를 모두 수집하면 로그량이 너무 많아지지 않나요?

A. 전혀 그렇지 않습니다.
요청본문·응답본문 로그는 흔히 NDR(Network Detection & Response) 과 비교되곤 하지만, 실제 로그 규모는 비교 자체가 성립하지 않습니다.

• NDR은 모든 패킷을 상시 수집·분석합니다.
• 반면 요청본문·응답본문 ...

더 읽기

Q02. 정말 100% 해킹 대응이 가능한가요?

A. 공격 ‘탐지’ 관점에서는 이미 가능합니다.

현재의 AI는 다음 조건이 충족될 경우,
공격 탐지에 있어 사실상 100% 정확도에 도달할 수 있습니다.

• 요청본문·응답본문 로그
• 운영체제 감사 로그(Audit Policy, auditd)
• 애플리케이션 및 시스템 행위 로...

더 읽기

Q03. 요청본문·응답본문 로그를 수집하면 개인정보 문제가 발생하지 않나요?

A. 수집 방식에 따라 충분히 통제 가능합니다.

요청본문·응답본문 로그는
원문 전체를 무조건 저장하는 방식이 아닙니다.

• 비밀번호, 주민번호, 카드번호 등은
  마스킹·해시·부분 수집 처리합니다.
• 특정 API, 특정 파라미터만 선별 수집도 가능합니다.
• 이상 행위 발생 시에...

더 읽기

Q04. 공급망 보안은 어떻게 해야 하나요?

A. 공격자는 항상 ‘가장 약한 고리’를 노립니다.

공급망을 관리해야 하는 중앙의 대기업은
충분한 예산과 인력, 보안 체계를 바탕으로
이미 적극적인 보안 투자를 진행하고 있습니다.

반면, 실제 공급망을 구성하는 다수의 공급 업체는 중소·중견 기업으로,...

더 읽기

Q05. 스마트 아파트 보안이 걱정되는데, 어떻게 대응해야 하나요?

A. 스마트 아파트의 모든 핵심 시스템은 웹 서비스입니다.

스마트 아파트 환경에서 사용되는 주요 구성 요소들은
겉보기에는 IoT·설비 장비처럼 보이지만,
실제로는 모두 웹 서버 기반으로 동작합니다.

예를 들면 다음과 같습니다....

더 읽기