정보처리안전확보지원사(情報処理安全確保支援士) 2023년 가을(레이와 5년) 오후 문제2 해설 ── 방문객용 Wi-Fi로 유출되는 파일

USB 메모리 연결을 금지했다. 로컬 디스크에 파일을 저장하는 것도 금지했다. 회사가 허용하지 않은 웹메일과 클라우드 스토리지로의 통신은 차단했다. 이메일에 파일을 첨부하는 것도 금지했다. 사내 파일 서버는 폐지했다.

그래도 업무용 파일은 유출할 수 있다.

정보처리안전확보지원사 시험 2023년 가을(레이와 5년도) 오후 문항2는, 이미 이만큼의 대책을 실시한 어패럴 업체 M사를 무대로 아직 남아 있는 구멍을 찾아내는 문제다¹. 이 글은 지난 회 문항1(저장형 XSS) 해설에 이어지는 시리즈의 두 번째 글로, 다루는 범위가 웹 애플리케이션에서 사내 네트워크와 단말 인증으로 옮겨간다.

문항1이 ‘웹 앱에 나열한 대책이 어디서 뚫렸는가’를 묻는 문제였다면, 문항2는 ‘대책의 설계가 어디까지 지키려던 것이었는가‘를 묻는 문제다. M사의 대책은 어느 것도 틀리지 않았다. 다만 지키는 범위를 하나씩 확인해 보면, 바로 그 바깥쪽이 비어 있다.

이 글에서 얻을 수 있는 것은 각 문항의 해답 예와 그 근거에 더해, 무선랜·서버 인증서·발신지 IP 주소 제한이라는 세 영역에 대해 실무에서 그대로 쓸 수 있는 점검 관점이다. 시험 대비로 읽는 분은 문항별 절을, 실무 관점만 필요한 분은 11장과 12장부터 읽어도 뜻이 통하도록 썼다.

1. 먼저 결론

• 빠져나갈 구멍은 회의실이었다. M사는 개인 소유 PC 반입을 금지했지만, 금지 대상은 집무실뿐이었고 회의실은 대상 밖이었다. 회의실에는 직원용 무선랜과 방문객용 무선랜이 모두 잡힌다
• 직원에 의한 유출 경로는 두 가지다. MAC 주소를 위장해 직원용 무선랜에 접속하는 방법과, 방문객용 무선랜에 접속하기만 하면 되는 방법. 후자가 훨씬 간단하며, 필요한 것은 방문객에게 나눠주는 사전 공유 키뿐이다
• 클라우드 스토리지(B서비스)는 ‘M사의 글로벌 IP 주소에서만 로그인 가능’하도록 제한하고 있었다. 그러나 방문객용 무선랜의 통신도 같은 NAT에서 같은 글로벌 IP 주소로 변환되기 때문에, 이 제한은 그대로 통과해 버린다. 발신지 IP 주소에 의한 제한은 단말이 아니라 출구를 공유하는 모든 사람을 허용하는 설정이다
• 사외 공격자에 의한 가짜 AP + 가짜 사이트는 서버 인증서 검증에서 멈춘다. 효과를 내는 것은 ‘신뢰된 인증 기관이 발급한 것인가’와 ‘인증서의 서버명이 접속 대상과 일치하는가’라는 두 가지다. IPA의 채점 강평에 따르면 이 두 가지를 답하게 하는 문항의 정답률은 낮았다
• http://라고 잘못 입력해도 HSTS가 HTTPS로 바꿔서 접속하므로, 역시 인증서 오류가 된다. 게다가 HSTS가 활성화된 호스트에서는 경고를 무시하고 계속 진행하는 선택지를 사용자에게 보여줘서는 안 된다
• 정규 파일 공유 기능도 유출 경로가 된다. 외부 공유자의 이메일 주소에 자신의 개인 주소를 지정하면 된다. 상사 승인은 있었지만, 수신자를 확인하지 않는 상사가 있었다
• 대책의 축은 세 가지다. 직원용 무선랜을 EAP-TLS로 바꿔 단말별 클라이언트 인증서로 인증하고, 개인 키는 TPM에 넣어 업무용 PC에서 꺼낼 수 없게 한다. 방문객용 무선랜은 M사의 네트워크에서 분리한다(또는 출구의 글로벌 IP 주소를 분리한다). 그리고 더 이상 쓰지 않는 VLAN·필터링 규칙·SSID를 삭제한다

2. 소재에 대해 ── 출처와 이 글에서의 취급

다루는 문제는 다음과 같습니다.

출처: 2023년 가을(레이와 5년도) 정보처리안전확보지원사 시험 오후 문항2

IPA는 공표하고 있는 과거 시험 문제에 대해, 법령에 특별한 규정이 있는 경우를 제외하면 허락이나 사용료가 필요 없다고 밝히고 있습니다. 다만 저작권을 포기한 것은 아니며, 출처를 ‘연도, 시기, 시험 구분, 시간 구분, 문항 번호 등’의 형식으로 명기할 것, 문제의 일부를 변경한 경우에는 그 사실도 명기할 것을 요구하고 있습니다².

이 글에서는 문제 책자에 실린 도표를 그대로 옮겨 싣지 않습니다. 구조를 설명하는 데 필요한 범위에서, 당사가 새로 작성한 간략도와 요약으로 대체하고 있습니다. 문항 문장과 해답 예도 요약해서 다룹니다. 문제 책자·해답 예·채점 강평의 원문은 IPA 페이지에서 무료로 다운로드할 수 있으므로, 곁에 펼쳐 두고 함께 읽으시길 권합니다^{1 3 4}.

문항과 이 글의 대응

풀고 싶은 문항 부분부터 읽기 시작해도 무방합니다.

문제 책자의 기술과 이 글에서의 취급

원문과 대조할 수 있도록, 어디를 어떻게 다뤘는지 정리합니다.

3. 문제의 무대 ── M사가 ‘이미 하고 있던 일’

M사는 L사의 자회사로, 어패럴업을 하는 직원 100명 규모의 회사입니다. 사옥은 인적이 많은 도심 대로변에 있습니다. 이 한 문장이 나중에 효과를 발휘합니다.

전년도에 M사 직원이 사내 파일 서버에 저장돼 있던 기밀 정보인 상품 디자인 파일을 USB 메모리에 저장해 경쟁사에 유출하는 사건이 일어났습니다. 모회사인 L사의 지도로 보안 대책 재검토가 진행되고 있습니다. 이미 실시를 마친 재검토는 다음 세 가지입니다.

• 직원에게 대여하는 노트북(이하 업무용 PC)에 정보 유출 방지 소프트웨어를 도입해, USB 메모리 등 외부 저장 매체 연결 금지, 소프트웨어 설치를 제외한 로컬 디스크 파일 저장 금지, 회사가 허용하지 않은 웹메일 및 클라우드 스토리지로의 통신 차단, 회사가 허용하지 않은 소프트웨어 설치 금지, 이메일 전송 시 파일 첨부 금지를 설정했다
• 업무용 파일의 저장 위치를, 이전부터 사용하던 클라우드 스토리지(이하 B서비스) 한 곳으로 통합하고 설정을 재검토했다
• 사내 파일 서버를 폐지했다

지난 사건이 ‘사내 파일 서버’ → ‘USB 메모리’라는 경로였으므로, 그 경로의 양 끝을 막은 형태입니다. 논리는 맞습니다.

네트워크 구성

사옥에는 집무실과 회의실이 있습니다. 집무실에서는 직원용 무선랜을 쓸 수 있고, 회의실에서는 직원용과 방문객용을 모두 쓸 수 있습니다. 회의실의 프로젝터는 방문객 반입 단말(방문객이 가져오는 PC·태블릿·스마트폰) 또는 업무용 PC를 방문객용 무선랜에 연결해 이용합니다.

설명에 필요한 범위만 그림으로 나타내면 다음과 같은 모습입니다.

flowchart LR
    subgraph M["M사의 사내 네트워크"]
        direction TB
        G["방문객용 무선랜<br/>192.168.10.0/24<br/>회의실 AP만"]
        E["직원용 무선랜<br/>192.168.20.0/24<br/>집무실과 회의실"]
        S["서버 네트워크<br/>192.168.30.0/24<br/>DHCP·DNS·디렉터리"]
        FW["FW<br/>NAT로 발신지를<br/>하나의 글로벌 IP<br/>주소로 변환"]
        G --> FW
        E --> FW
        S --> FW
    end
    FW --> B["B서비스<br/>클라우드 스토리지"]
    FW --> I["인터넷"]

짚어 둬야 할 사양은 다음과 같습니다.

그리고 보안 규칙이 세 가지 있습니다. 업무용 PC의 사외 반출은 금지, 개인 소유 PC·태블릿·스마트폰 등의 집무실 반입은 금지, 업무용 파일의 사외 반출은 B서비스의 파일 공유 기능 이외의 방법으로는 금지.

두 번째 규칙에 ‘집무실로의’라고 적혀 있다는 점을 눈치채셨나요. 회의실은 적혀 있지 않습니다.

이 문제가 전개되는 방식

정보시스템부의 Y씨가 모회사 L사의 정보처리안전확보지원사(등록 세키스페)인 S씨의 지원을 받으며, B서비스로부터의 파일 유출에 대해 대책이 충분한지 확인해 나갑니다. 두 사람은 사외 공격자에 의한 유출과 직원에 의한 유출을 나누어 검토합니다. 문항1이 전자, 문항2가 후자, 문항3이 대책 수립입니다.

4. 가짜 Wi-Fi와 가짜 사이트 ── 문항1(1)(2)

먼저 Y씨가 제시하는 것은, 방문객용 무선랜을 이용한 적이 있는 방문객이 공격자가 되어 M사 근처에서 방문객용 무선랜에 접속해 B서비스에 접속한다는 시나리오입니다.

이 시나리오가 성립해 버리는 이유는 무선랜 인증 방식이 WPA2-PSK이기 때문입니다. PSK(Pre-Shared Key, 사전 공유 키)는 이름 그대로 모두가 같은 키를 공유하는 방식입니다. 방문객용 무선랜의 사전 공유 키는 방문객에게 알려주기 위한 것입니다. 한 번 알려주고 나면, 그 사람이 앞으로도 알고 있다는 상태를 취소할 방법이 없습니다(전원의 키를 바꾸는 수밖에 없습니다). 게다가 사옥이 인적이 많은 대로변에 있으므로, 건물 밖에서도 전파가 닿습니다.

이에 대한 S씨의 답은 명쾌합니다. B서비스에 로그인하려면 [a] 사용자 ID 와 [b] 비밀번호 가 필요하다는 것입니다. 이것이 문항1(1)의 해답 예입니다(순서 무관). 무선랜에 접속하는 것 자체는 B서비스 로그인을 의미하지 않습니다.

가짜 AP와 가짜 사이트

그래서 Y씨는 한 단계 더 나아간 시나리오를 제시합니다. 방문객용 무선랜 AP와 같은 설정의 가짜 AP와, B서비스와 같은 URL의 가짜 사이트를 준비하고, DNS 설정을 조작해 사용자 ID와 비밀번호를 훔치는 방법은 어떤가. 가짜 AP를 M사 근처에 두면, M사 직원이 업무용 PC를 실수로 가짜 AP에 접속시키고, B서비스에 접속하려다 가짜 사이트에 접속해 로그인해 버릴지도 모른다는 것입니다.

이른바 evil twin(악마의 쌍둥이)입니다. 방문객용 무선랜과 같은 SSID·같은 사전 공유 키로 AP를 세우면, 단말 입장에서는 정규 AP와 구별할 수 없습니다. WPA2-PSK에서 단말이 AP에 대해 확인할 수 있는 것은 ‘같은 사전 공유 키를 알고 있다는 것‘뿐이기 때문입니다. 키를 모르는 AP는 접속 절차를 완료할 수 없지만, 거꾸로 말하면 키를 아는 사람이라면 누구나 ‘진짜 AP’가 될 수 있습니다. 방문객에게 나눠주는 키인 이상, 그것은 공격자에게도 전달되어 있다고 봐야 합니다.

S씨의 답은 여기서도 명쾌합니다. 직원이 HTTPS로 가짜 사이트에 접속하려 하면, 안전한 연결이 아니라는 오류 메시지와 함께, 가짜 사이트에 사용된 서버 인증서에 따라 다음 4개 항목 중 하나 이상이 웹 브라우저에 표시됩니다.

• 이 서버 인증서는 신뢰된 인증 기관이 발급한 서버 인증서가 아닙니다(빈칸 c)
• 이 서버 인증서에 기재된 서버명은 접속 대상 서버명과 다릅니다(빈칸 d)
• 이 서버 인증서는 폐기(실효)되었습니다
• 이 서버 인증서는 유효기간이 만료되었습니다

이 중 아래 2개 항목은 문제 책자에 처음부터 적혀 있으며, 위 2개 항목(빈칸 c·d, 각각 40자 이내·순서 무관)을 답하는 것이 문항1(2)입니다.

sequenceDiagram
    autonumber
    participant U as 직원의 업무용 PC
    participant F as 가짜 AP·가짜 사이트<br/>(공격자)
    participant B as B서비스(정규)

    Note over F: 방문객용 무선랜과 같은 SSID·<br/>같은 사전 공유 키로 AP를 세운다
    U->>F: 실수로 가짜 AP에 접속
    Note over F: DNS를 조작해 B서비스의<br/>도메인명을 가짜 사이트로 향하게 한다
    U->>F: HTTPS로 B서비스의 URL에 접속
    F-->>U: 가짜 사이트의 서버 인증서
    Note over U: 검증에서 불합격 처리됨<br/>·신뢰된 인증 기관의 발급이 아님<br/>·인증서의 서버명이 접속 대상과 다름
    Note over U: 안전한 연결이 아니라는 오류를 표시<br/>로그인 화면은 표시되지 않음
    Note over U,B: 정규 B서비스와는<br/>애초에 통신하지 않고 있음

인증서 검증은 무엇을 보는가

채점 강평은 이 문항에 대해 다음과 같이 적고 있습니다.

문항1(2)는 정답률이 낮았다. 공격자가 가짜 사이트를 준비했다 하더라도, HTTPS로 접속하는 경우라면 서버 인증서 검증에 실패한다. 서버 인증서 검증은 통신의 안전성을 확보하는 데 있어 기본적인 지식이므로, 구체적으로 어떤 사항을 검증하는지까지 포함해 잘 이해해 두기를 바란다.

‘인증서 오류가 뜬다’는 것은 알아도, 무엇을 확인해서 불합격 판정이 나는지를 4개 항목으로 분해할 수 있는 사람이 적었다는 뜻입니다. 그림2가 제시하는 4개 항목을, 각각 무엇을 위한 확인인지라는 관점에서 정리하면 다음과 같습니다.

공격자 입장에서 보면 위의 두 항목이 넘을 수 없는 벽이 됩니다. 자기서명 인증서를 만들면 첫 번째에서 걸리고, 자신의 도메인(예를 들어 b-service.example.net)용으로 무료 인증서를 정규로 취득해도 접속 대상은 B서비스의 도메인이므로 두 번째에서 걸립니다. B서비스의 도메인명에 대한 인증서는 B서비스의 도메인을 관리하고 있지 않으면 취득할 수 없기 때문입니다. 이 두 가지의 조합이 인증서라는 구조의 본체라고 해도 좋을 것입니다.

인증서의 경로 검증 절차는 RFC 5280이⁵, 인증서에 적힌 이름과 접속 대상 이름을 대조하는 절차는 RFC 6125가⁶ 규정하고 있습니다.

4개 항목이 같은 강도로 작동하는 것은 아니다

여기서 시험의 답과 실제 브라우저의 동작을 구분해 두겠습니다. 위의 4개 항목은 문제문의 그림2가 ‘표시될 수 있는 오류의 상세’로 제시한 것일 뿐이며, 어떤 브라우저든 4가지를 똑같은 확실성으로 검사한다고 읽어서는 안 됩니다.

발급자·서버명·유효기간의 세 가지는 인증서를 받은 시점에 손에 있는 정보만으로 판정할 수 있으므로 반드시 검증됩니다. 이 문제의 공격을 막고 있는 것도 이 세 가지입니다.

한편 실효 확인만은 성질이 다릅니다. 실효 여부는 인증서 안에 적혀 있지 않고 별도의 정보를 가져와야 하므로, 구현과 설정에 따라 달라집니다.

• Chrome은 온라인 OCSP나 CRL 확인을 평소에는 하지 않습니다. 대신 긴급 시 인증서를 신속히 차단하는 것을 주목적으로 한 CRLSet이라는 한정된 목록을 배포하고 있으며, CA의 실효 목록에서 반영되는 것은 그중 일부입니다⁷
• OCSP를 조회하는 구현이라도, 응답을 받지 못했을 때 연결을 그대로 통과시키는(소프트 페일, soft-fail) 구성이 널리 쓰이고 있습니다

따라서 ‘개인 키가 유출되면 실효시키면 된다’를 대책의 축으로 삼지 마십시오. 실효는 해야 할 일이지만, 모든 사용자의 브라우저에서 확실히 작동하는 장치가 아닙니다. 최근 인증서 유효 기간이 짧아지고 있는 것도, 실효를 믿을 수 없다는 문제에 대한 업계 쪽의 답이기도 합니다. 자사에서 키 유출이 의심될 때는 실효 신청과 함께, 인증서 교체와 그 키로 지키고 있던 것(세션, API 키 등)의 무효화까지 손을 써야 합니다.

실무에서의 함정 ── ‘신뢰된 인증 기관’은 누가 정하는가

여기서부터는 문제문 밖의 이야기입니다. 위 표의 첫 번째 항목은 그 단말이 무엇을 신뢰하고 있는가에 따라 달라집니다. 신뢰 목록은 브라우저나 OS가 갖고 있으며, Windows라면 인증서 저장소의 ‘신뢰할 수 있는 루트 인증 기관’이 여기에 해당합니다.

즉, 다음과 같은 상황에서는 첫 번째 확인을 통과해 버립니다.

• 사내 인증 기관(프라이빗 CA)의 루트 인증서를 업무용 PC에 배포하고 있다. 그 CA의 개인 키, 또는 인증서 발급 절차를 공격자가 장악했다
• 통신 내용을 검사하는 프록시나 보안 제품이 TLS를 종단하기 위해 자체 루트 인증서를 단말에 넣어 두고 있다. 그 제품이나 운영이 공격자에게 장악됐다
• ‘인증서 오류가 뜨니까’라는 이유로, 과거에 누군가가 예외를 등록했거나 자기서명 인증서를 신뢰된 루트에 넣었다

세 번째는 현장에서 정말 자주 봅니다. 사내 시스템의 인증서 오류를 없애기 위해 누군가 한 번 수동으로 넣은 것이, 퇴직자의 PC에서 물려받은 이미지에 계속 남아 있는 식입니다. 신뢰할 수 있는 루트 인증 기관 저장소의 내용은 그 단말이 누구를 신뢰하는가에 대한 선언 그 자체이므로, 점검 대상으로 삼으십시오. 어느 저장소에 무엇을 넣어야 하는가에 대한 판단은 Windows 인증서 저장소 실무 가이드에서 정리하고 있습니다.

두 번째 확인(서버명 일치)에 대해서는 실무에서 별도의 주의점이 있습니다. 사용자가 도메인명을 잘못 보는 공격에는 인증서가 무력합니다. 공격자가 b-serv1ce.example.com처럼 헷갈리기 쉬운 도메인을 취득하고, 그 도메인용으로 정규 인증서를 취득했다면 브라우저는 오류를 내지 않습니다. 인증서가 보증하는 것은 ‘접속 대상 서버명과 인증서의 서버명이 일치한다는 것’이지, ‘그 서버명이 사용자가 의도한 상대라는 것’이 아닙니다. 이 마지막 한 걸음을 사용자의 육안 확인에 의존하지 않는 방식이, 패스키(WebAuthn)처럼 오리진을 인증기 쪽에서 검증하는 방식입니다. 자세한 내용은 패스키는 왜 안전한가에서 다루고 있습니다.

5. http://라고 잘못 입력해도 멈추는 이유 ── 문항1(3)

Y씨는 물러서지 않습니다. 가짜 AP에 접속한 상태에서, 직원이 웹 브라우저에 B서비스의 URL을 입력할 때 실수로 http://라고 입력해 버리면, 오류 메시지가 표시되지 않는 것 아니냐고 말입니다.

지당한 의문입니다. HTTP로 접속한다면 애초에 서버 인증서가 등장하지 않습니다. 가짜 사이트는 아무런 오류도 내지 않고 로그인 화면을 표시할 수 있을 것 같습니다.

S씨의 답은 ‘괜찮습니다. HSTS를 활성화해 두었으므로, 그 경우에도 방금과 같은 오류 메시지가 표시됩니다’였습니다. 문항1(3)은 이 오류 메시지가 표시되기 직전까지 웹 브라우저의 동작을 60자 이내로 묻습니다.

해답 예는 ‘HTTP 접속을 HTTPS 접속으로 바꾸어 접속한다. 그 후 가짜 사이트로부터 서버 인증서를 받는다‘입니다.

브라우저 안에서 무슨 일이 일어나는가

HSTS(HTTP Strict Transport Security)는 사이트가 Strict-Transport-Security 헤더로 ‘앞으로 이 호스트에는 반드시 HTTPS로 오라’고 선언하고, 브라우저가 그것을 기억해 두는 구조입니다. RFC 6797이 규정하고 있습니다⁸.

기억하고 있는 호스트에 http://로 접속하려 할 때, 브라우저는 다음과 같이 동작합니다.

1. URL의 스킴을 http에서 https로 바꾼다. 포트 80이 명시되어 있으면 443으로 변환한다(RFC 6797 8.3절)
2. 그 결과 HTTPS로 접속한다. 이때 DNS가 조작되어 있으므로 접속 대상은 가짜 사이트
3. 가짜 사이트로부터 서버 인증서를 받는다
4. 검증에 실패해 4장과 같은 오류가 된다

중요한 것은 1의 치환이 네트워크로 나가기 전에 완료된다는 점입니다. 평문 HTTP 요청은 애초에 전송되지 않습니다. 그래서 ‘HTTP로 접속했으니 인증서가 등장하지 않는다’는 상황이 되지 않는 것입니다.

‘무시하고 진행’을 누를 수 없다

또 한 가지, HSTS에는 실무상 매우 중요한 성질이 있습니다. RFC 6797의 8.4절은 HSTS가 활성화된 호스트와의 안전한 통신로를 수립하는 중에 오류가 발생한 경우, 경고이든 치명적이든 접속을 중단할 것을 요구합니다. 그리고 12.1절은 그 동작을 “No User Recourse”(사용자에게 회피 수단을 주지 않음)라고 표현하며, ‘이 연결은 안전하지 않지만 계속하시겠습니까’와 같은 선택지를 제시해서는 안 된다고 명시하고 있습니다.

일반적인 인증서 오류라면 많은 브라우저가 경고 화면에 ‘고급 설정’, ‘계속 진행’ 같은 도선을 마련해 두고 있습니다. 실무에서는 사내 시스템의 인증서 오류에 익숙해진 사용자가 이를 반사적으로 누르는 광경이 드물지 않습니다. HSTS는 그 반사 행동을 봉쇄합니다. 가짜 사이트에 대한 방어로서는 인증서 검증 자체보다, 이 ‘누를 수 없다’는 점이 더 효과적이라고까지 말할 수 있습니다.

HSTS의 전제 ── 첫 접속만큼은 지킬 수 없다

다만 HSTS에는 전제 조건이 있습니다. RFC 6797의 8.1절이 정하는 대로, 어떤 호스트가 ‘기지(旣知)의 HSTS 호스트’가 되는 것은 사용자 에이전트가 안전한 통신로 위에서 Strict-Transport-Security 헤더를 받았을 때입니다. 즉, 그 브라우저가 한 번은 정규 사이트에 HTTPS로 도달한 적이 있어야 합니다.

따라서 다음의 경우에는 보호되지 않습니다.

• 새로 배포한 지 얼마 안 된 업무용 PC에서, 첫 접속이 처음부터 가짜 AP 아래에서 이루어졌다
• 브라우저 프로필을 새로 만들었거나, 열람 데이터를 지워서 HSTS 기록도 함께 사라졌다
• 기록의 유효 기간(max-age)이 지났다

이 첫 접속 문제를 메우는 것이 HSTS 프리로드 목록입니다. 미리 브라우저에 내장된 도메인 목록에 올라 있으면, 한 번도 접속한 적이 없어도 HTTPS가 강제됩니다.

다만 자사 사이트의 등록을 검토한다면 먼저 조건을 확인하십시오. 등록 요건은 다음과 같습니다⁹.

• 유효한 인증서를 제공하고 있을 것
• 포트 80에서 대기하고 있다면, 동일 호스트에서 HTTP를 HTTPS로 리다이렉트할 것
• 모든 서브도메인을 HTTPS로 제공하고 있을 것(DNS 레코드가 있다면 www도 포함)
• 베이스 도메인에서 max-age를 31536000초(1년) 이상으로 하고, includeSubDomains, preload를 붙인 Strict-Transport-Security 헤더를 반환할 것

효과를 발휘하는 것은 세 번째 항목과 includeSubDomains의 조합입니다. 사내용의 오래된 서브도메인이 HTTP 전용이거나 인증서를 준비해 두지 않았다면, 등록하는 순간 그곳에 도달할 수 없게 됩니다. 등록 전에 서브도메인을 모두 점검하십시오.

그리고 취소는 간단하지 않습니다. 삭제 신청은 일반적으로 접수되지만, 변경 사항이 사용자의 브라우저에 반영되기까지 몇 개월이 걸리며, Chrome 이외의 브라우저에 대해서는 보장이 없습니다⁹. 프리로드는 ‘틀리면 되돌리면 그만’인 설정이 아니라고 여기고 임하는 것이 안전합니다.

반대로 이용하는 쪽 입장에서는, 업무에 사용하는 클라우드 서비스가 HSTS를 지원하는가를 선정 시 확인 항목에 넣어도 좋은 관점입니다.

6. 승인이 형식화되는 순간, 공유 기능은 유출 경로가 된다 ── 문항2(1)

여기서부터는 직원에 의한 유출 검토로 넘어갑니다.

S씨는 먼저 파일 공유 기능의 운용 상태를 확인합니다. 상사는 수신자 이메일 주소와 파일을 제대로 확인한 뒤 승인하고 있는가. Y씨의 답은 ‘확인하지 않는 상사도 있는 것 같습니다’였습니다.

여기서 S씨가 지적하는 것이 문항2(1)입니다. M사 외부에서 파일을 다운로드할 수 있게 하기 위한, 파일 공유 기능의 악용 방법을 40자 이내로 구체적으로 답합니다.

해답 예는 ‘외부 공유자의 이메일 주소에 자신의 개인 이메일 주소를 지정한다‘입니다.

설계는 옳고, 운용에 구멍이 있다

B서비스의 파일 공유 기능은 잘 설계되어 있습니다.

• 공유에는 상사의 승인이 필요
• 외부 공유 링크는 본인에게도 상사에게도 알려주지 않는다. 공유자 본인이 링크를 전달해 유출할 수는 없다
• 링크는 추측하기 어려운 무작위 문자열을 포함하며, 유효 기간은 1일

특히 두 번째는 내부로부터의 유출을 의식한 설계입니다. 그래도 뚫립니다. 수신자를 자신으로 해 버리면, ‘본인에게 알려주지 않는’ 링크가 본인의 손에 들어오기 때문입니다.

그리고 이 빠져나갈 구멍이 열리기 위한 조건은 딱 하나, ‘상사가 수신자를 확인하지 않는 것’입니다. 승인 워크플로는 승인자가 내용을 보는 것을 전제로 설계되어 있습니다. 보지 않는다면 그것은 자동화된 배송 경로에 지나지 않습니다.

승인이 형식화되는 조건은 정해져 있다

실무에서 승인이 형식화될 때, 원인은 대체로 다음 중 하나입니다.

이 문제의 M사에 부족한 것은 주로 마지막 두 가지입니다. 승인을 통과시키는 장치를 넣었다면, 승인한 결과를 나중에 볼 수 있는 장치도 필요합니다. 프리메일 도메인 앞의 외부 공유가 한 달에 몇 건 있었는지 목록으로 볼 수 있는 것만으로도 이런 수법은 훨씬 찾기 쉬워집니다.

중소기업이 어디서부터 손을 대야 하는가에 대한 전체 그림은 중소기업의 보안 대책, 무엇부터 시작할까 ── IPA 「중소기업의 정보보안 대책 가이드라인」제4.0판 활용법에서 다루고 있습니다.

7. 회의실이라는 빠져나갈 구멍 ── 문항2(2)

S씨의 다음 질문은 ‘회의실에는 개인 소유 PC를 반입할 수 있습니까’였습니다. Y씨의 답은 ‘회의실 반입은 금지하고 있지 않으므로 반입할 수 있습니다’였습니다.

여기서 방법1과 방법2가 등장합니다. 둘 다 개인 소유 PC로 B서비스에서 파일을 다운로드하고, 그 개인 소유 PC를 통째로 가지고 나간다는 줄거리입니다. 업무용 PC에 설정한 정보 유출 방지 소프트웨어는 개인 소유 PC에는 전혀 작동하지 않습니다.

방법1 ── MAC 주소 위장

방법1은 개인 소유 PC의 무선랜 인터페이스 [e] MAC 주소를 업무용 PC의 무선랜 인터페이스 MAC 주소로 변경한 다음, 개인 소유 PC를 직원용 무선랜에 접속시키는 것입니다. 빈칸 e를 답하는 것이 문항2(2)입니다.

직원용 무선랜의 입구를 지키고 있던 것은 WPA2-PSK의 사전 공유 키와 MAC 주소 필터링, 이 두 가지였습니다. 둘 다 직원이라면 넘을 수 있습니다.

• 사전 공유 키는 업무용 PC에 설정된 것이며, 직원은 업무용 PC의 사용자입니다. 모두가 하나의 키를 공유하는 방식인 이상, ‘사용자는 알 수 있다’고 보는 것이 전제입니다
• MAC 주소는 단말 쪽에서 다시 쓸 수 있습니다. OS 설정이나 드라이버 속성에서 변경할 수 있는 것이 보통이며, 특별한 도구는 필요 없습니다. 게다가 무선랜 프레임에 실려 있는 MAC 주소는 암호화되지 않으므로, 근처에서 전파를 수신하면 등록된 업무용 PC의 MAC 주소를 알아낼 수도 있습니다

MAC 주소 필터링과 SSID 비공개는 오접속을 줄이는 정리 정돈으로서는 의미가 있습니다. 하지만 의도적으로 침입하려는 상대를 막는 인증 장치는 아닙니다. 이 두 가지를 ‘대책’의 수에 포함시키고 있지는 않은지, 자사의 구성에서도 확인해 보십시오.

방법2 ── 그냥 방문객용 무선랜에 연결하기만 하면 된다

방법2는 더 단순합니다. 개인 소유 PC를 방문객용 무선랜에 접속시키고, B서비스에서 파일을 다운로드하고, 개인 소유 PC를 통째로 가지고 나간다. 그게 전부입니다.

MAC 주소 위장도 필요 없습니다. 필요한 것은 방문객용 무선랜의 사전 공유 키뿐이며, 이것은 방문객에게 나눠주는 것입니다. 직원이 모를 리가 없습니다.

여기서 당연히 다음 의문이 생깁니다. B서비스는 ‘M사 직원에게 할당된 사용자 ID로는 M사의 글로벌 IP 주소에서만 로그인 가능’하도록 제한하고 있었던 것 아니냐고 말입니다.

발신지 IP 주소 제한은 무엇을 허용하고 있는가

문제문의 방화벽 설정을 읽어 보면 답이 나와 있습니다. 방문객용 무선랜에서 인터넷으로 나가는 통신도, 직원용 무선랜에서의 통신도, 같은 NAT에서 같은 하나의 글로벌 IP 주소로 변환되고 있는 것입니다.

B서비스 입장에서 보면 이 세 가지는 구별할 수 없습니다. IP 주소에 의한 제한은 그대로 통과됩니다.

이 구도는 시험 밖에서도 반복해서 나타납니다. 발신지 IP 주소에 의한 제한은 ‘이 단말에서만’을 의미하지 않습니다. ‘이 글로벌 IP 주소로 나가는 모든 사람에게서’를 의미합니다. 허용하고 있다고 생각하는 범위와 실제로 허용되는 범위가 어긋나는 전형적인 예를 들겠습니다.

발신지 IP 주소에 의한 제한이 무의미하다는 이야기가 아닙니다. 제한을 한 장만 쓰지 말라는 이야기입니다. IP 주소로 좁힌 위에, 단말 자체를 식별하는 장치(클라이언트 인증서나 디바이스 인증서)나 사용자를 식별하는 장치(다요소 인증)를 겹쳐야 비로소 ‘이 단말의, 이 사람이’를 표현할 수 있습니다. 이 문제의 대책도 바로 그 방향으로 나아갑니다.

8. 단말을 인증서로 묶다 ── 문항3(1)~(4)

방법1에 대한 대책으로, M사는 직원용 무선랜의 인증 방식으로 EAP-TLS를 선택하고 인증 서버를 마련하기로 했습니다.

문항3(1) ── RADIUS

문항3(1)은 인증 서버가 EAP에서 사용하는 UDP 기반 프로토콜을 묻습니다. 해답 예는 RADIUS입니다.

구도를 정리하면 등장인물은 3자입니다.

업무용 PC와 AP 사이는 IEEE 802.1X(EAP over LAN), AP와 인증 서버 사이는 RADIUS입니다. RADIUS는 UDP 위에서 동작합니다¹⁰. EAP-TLS 자체의 절차는 RFC 5216이 규정하고 있습니다¹¹. Windows Server로 구성할 경우, 인증 서버 역할을 맡는 것은 네트워크 정책 서버(NPS)입니다¹².

WPA2-PSK에서 EAP-TLS로 옮겨가면 무엇이 달라지는지 짚어 두겠습니다.

마지막 행은 보충이 필요합니다. EAP-TLS에서 클라이언트가 인증서를 검증하는 상대는 AP가 아니라 인증 서버입니다. AP는 EAP 주고받기를 중계하는 인증자에 지나지 않으며, 클라이언트는 AP 자체의 신원을 확인하는 것이 아닙니다.

그럼에도 4장의 evil twin에 대한 대비가 되는 것은, 인증이 성공해야 비로소 생성되는 키 자재가 RADIUS의 공유 비밀을 가진 정규 AP에만 전달되기 때문입니다. 공격자가 마음대로 세운 AP는 그 뒤에 정규 인증 서버를 두지 않는 한 이 절차를 끝까지 진행할 수 없습니다. 클라이언트가 직접 검증하는 것은 인증 서버이며, AP의 정당성은 거기서 간접적으로 도출되는 구조입니다.

다만 조건이 있습니다. 클라이언트 쪽에서 ‘어느 인증 기관이 발급한, 어떤 이름의 서버 인증서라면 신뢰할 것인가’를 설정해 두지 않으면, 공격자가 자체 인증 서버를 준비했을 때 구별할 수 없습니다. EAP-TLS를 도입했는데도 클라이언트 프로필에서 서버 인증서 검증을 비활성화해 둔 구성이 실제로 존재합니다. 도입했다면 그 부분까지 포함해 확인하십시오.

문항3(2) ── 채점 강평이 지적한 오답

Y씨의 설명은 이렇게 이어집니다. 클라이언트 인증서는 CA 서버를 새로 마련해 발급하며, 직원이 자신의 업무용 PC에 직접 설치하는 것이 아니라 디렉터리 서버의 기능으로 업무용 PC에 저장한다. 그리고 클라이언트 인증서에 대응하는 [f] 는 [g] 해 두기 위해 업무용 PC의 TPM에 저장해 보호한다는 것입니다.

문항3(2)는 빈칸 f를 묻습니다. 해답 예는 개인 키입니다.

채점 강평은 다음과 같이 적고 있습니다.

문항3(2)는 정답률이 다소 높았으나, ‘공개 키’나 ‘서버 인증서’와 같은 답안이 일부 있었다. PKI는 다양한 보안 기술의 기초가 되는 중요한 기술이므로, 어떤 상황에서 어떻게 이용되는지 잘 이해해 두기를 바란다.

공개 키는 인증서 안에 들어가 전 세계에 배포되는 것입니다. 지켜야 할 대상이 아닙니다. 지켜야 하는 것은 그 인증서의 소유자만 갖고 있어야 할 개인 키입니다. ‘클라이언트 인증서로 인증한다’는 것은 정확히 말하면 ‘인증서에 들어 있는 공개 키에 대응하는 개인 키를 갖고 있음을, 그 키로 서명해 보임으로써 증명한다’는 것입니다. 그러므로 개인 키를 복제할 수 있게 되면, 인증서에 의한 인증은 의미를 잃습니다.

TPM에 넣으면 무엇이 달라지는가 ── 문항3(3)

문항3(3)은 빈칸 g를 20자 이내로 묻습니다. 해답 예는 ‘업무용 PC에서 꺼낼 수 없도록‘입니다.

개인 키를 파일로 단말에 두었을 경우, 그것은 복사할 수 있는 데이터입니다. 개인 소유 PC에 복사하면 그 개인 소유 PC가 업무용 PC로서 인증을 통과합니다. 방법1(MAC 주소 위장)을 막았다고 생각했지만, ‘인증서 위장’으로 바뀔 뿐입니다.

TPM은 키를 그 안에서 생성해, 밖으로 꺼낼 수 없는 상태로 유지할 수 있습니다. 서명 등의 연산은 TPM 안에서 이루어지며, 키 자체는 OS에도, 애플리케이션에도, 악성코드에도 넘어가지 않습니다. 결과적으로 그 개인 키는 그 한 대의 물리적 부품에 고정됩니다.

Windows에서 구현할 경우, 인증서 템플릿의 키 저장소 공급자(KSP)에 Microsoft Platform Crypto Provider를 지정합니다. 이 공급자는 TPM을 이용해 키를 보호하는 것으로, 인증서 템플릿 쪽에서 ‘개인 키 내보내기 허용’에 체크가 되어 있으면 선택할 수 없습니다¹³. 내보낼 수 있다면 보호하는 의미가 없다는, 당연한 제약입니다.

TPM이라는 부품의 역할 자체에 대해서는 BitLocker 실무 가이드에서 드라이브 암호화의 맥락으로 다루고 있습니다. ‘개인 키를 디바이스 밖으로 내보내지 않는다’는 사고방식은 패스키는 왜 안전한가에서 설명하는 인증기 설계와 같은 발상입니다.

왜 ‘문제없다’고 말할 수 있는가 ── 문항3(4)

Y씨의 설명을 들은 S씨는 ‘그 저장 방법이라면 문제없다고 생각합니다’라고 답합니다. 문항3(4)는 그 이유를 40자 이내로 묻습니다.

해답 예는 ‘EAP-TLS에 필요한 인증 정보는 업무용 PC에만 저장할 수 있기 때문‘입니다.

흐름을 따라가면 이렇게 됩니다.

1. 클라이언트 인증서는 직원이 직접 설치하는 것이 아니라, 디렉터리 서버의 기능으로 업무용 PC에 배포된다. 직원의 손을 거치지 않는다
2. 개인 키는 TPM 안에 있으며, 업무용 PC에서 꺼낼 수 없다
3. 따라서 EAP-TLS로 직원용 무선랜에 접속할 수 있는 것은 회사가 배포한 업무용 PC뿐이게 된다
4. 개인 소유 PC는 MAC 주소를 위장해도 인증을 통과시킬 수 없다. 방법1은 봉쇄된다

‘그 저장 방법이라면‘이라는 조건부 표현에 주의하십시오. 만약 개인 키를 파일로 업무용 PC에 두었다면, S씨는 문제없다고 말하지 않았을 것입니다. 같은 ‘클라이언트 인증서에 의한 인증’이라도, 개인 키를 두는 방식에 따라 지킬 수 있는 범위가 달라집니다.

TPM이 지키지 않는 것

한편 TPM에 넣으면 안심이라는 이야기는 아닙니다. TPM이 보증하는 것은 ‘그 키가 다른 단말로 복제되지 않는다는 것’뿐입니다. 다음의 것들은 지키지 않습니다.

• 단말 자체를 반출당한 경우. 업무용 PC를 반출하면 TPM까지 통째로 반출한 것이 됩니다. M사의 규칙에서는 업무용 PC의 사외 반출이 금지되어 있지만, 규칙과 기술적 강제는 별개입니다. 드라이브 암호화(부팅 전 인증 포함)와 분실 시 인증서를 실효시키는 운용이 별도로 필요합니다
• 사용자 사칭. TPM은 단말을 식별하지만, 그 단말을 조작하는 사람이 누구인지는 보증하지 않습니다. 사용자 인증은 별도로 필요합니다
• 단말에서 동작하는 악성코드. 개인 키는 읽어낼 수 없지만, 그 단말에서 동작하는 코드는 ‘TPM에 서명을 요청’할 수는 있습니다. 키의 복제는 막을 수 있어도, 그 단말이 장악당하고 있는 동안의 악용은 막지 못합니다

9. 출구의 IP 주소를 분리하다 ── 문항3(5)

방법2(방문객용 무선랜에 연결하기만 하면 되는 방법)에 대한 대책으로, M사는 두 가지 안을 검토합니다. FW의 NAT 설정을 변경하는 안과, 무선랜 서비스(D서비스)를 이용하는 안입니다.

문항3(5)는 전자의 변경 내용을 70자 이내로 묻습니다. 해답 예는 ‘방문객용 무선랜에서 인터넷에 접속할 경우의 발신지 IP 주소를, 현재 사용 중인 글로벌 IP 주소와는 다른 IP 주소로 한다‘는 취지의 것입니다(문제문에서는 그 글로벌 IP 주소를 a1.b1.c1.d1로 표기하고 있습니다).

7장에서 본 대로, 방법2가 성립하는 것은 방문객용 무선랜의 통신이 직원과 같은 글로벌 IP 주소로 나가기 때문이었습니다. 그렇다면 방문객용 무선랜만 다른 글로벌 IP 주소로 변환하면 됩니다. B서비스 쪽의 IP 주소 제한은 바꾸지 않은 채, 방문객용 무선랜에서의 접속만 그 범위에서 벗어나게 됩니다.

이것이 성립하는 것은 M사의 WAN 쪽에 복수의 글로벌 IP 주소가 할당되어 있기 때문입니다. 문제문의 FW 인터페이스 설정을 읽어 보면, WAN 쪽 서브넷 마스크가 255.255.255.248, 즉 /29이며 사용 가능한 주소가 하나가 아님을 알 수 있습니다. 문제문의 표를 꼼꼼히 읽게 만드는, 수수하지만 확실한 복선입니다.

자사에서 같은 방법을 쓸 수 있는지는 계약한 회선에서 글로벌 IP 주소를 여러 개 쓸 수 있는가에 달려 있습니다. 하나뿐이라면 이 안은 쓸 수 없습니다. 그 경우에는 다음 장의 분리안이 됩니다.

10. 더 이상 쓰지 않는 설정을 지우는 것까지가 대책 ── 문항3(6)(7)

검토 결과, M사는 D서비스를 이용하기로 했습니다.

• 회의실에 D서비스에서 대여한 무선랜 라우터(D라우터)를 설치한다
• D라우터에서는 DHCP 서버 기능과 DNS 캐시 서버 기능을 활성화한다
• 방문객 반입 단말은 M사의 네트워크를 거치지 않고, D라우터에 탑재된 SIM을 이용해 인터넷에 접속한다
• 프로젝터는 방문객용 무선랜을 쓰지 않고 HDMI 케이블로 연결하는 방식으로 변경한다

flowchart LR
    subgraph M["M사의 사내 네트워크 - 대책 후"]
        direction TB
        E["직원용 무선랜<br/>EAP-TLS + RADIUS<br/>개인 키는 TPM 안에"]
        S["서버 네트워크"]
        FW["FW"]
        E --> FW
        S --> FW
    end
    subgraph K["회의실"]
        T["방문객 반입 단말"]
        D["D라우터<br/>SIM으로 인터넷에 직접 연결"]
        T --> D
    end
    FW --> B["B서비스"]
    D --> I["인터넷"]

방문객용 네트워크가 M사의 네트워크로부터 물리적으로도 논리적으로도 분리되었습니다. 같은 글로벌 IP 주소로 나가는 일도 없습니다.

문항3(6) ── 불필요해지는 통신

방문객 반입 단말이 M사의 네트워크를 쓰지 않게 되면, 지금까지 필요했던 DHCP 서버와 [h] 서버로의 통신이 불필요해집니다. 빈칸 h의 해답 예는 DNS입니다.

D라우터 자체가 DHCP 서버 기능과 DNS 캐시 서버 기능을 갖고 있으므로, 방문객 반입 단말은 M사의 서버 네트워크에 있는 DHCP 서버·DNS 서버를 쓸 필요가 없어집니다. 문제문의 설명을 다시 읽어 보면 그대로 적혀 있습니다.

문항3(7) ── 지워야 할 설정을 모두 든다

문항3(7)은 이 변경에 따라 FW의 VLAN 인터페이스 설정과 필터링 설정에서 삭제해야 할 항목 번호를 각각 모두 답하게 합니다.

정답은 VLAN 인터페이스 설정에서는 방문객용 무선랜의 VLAN(항목 번호 1), 필터링 설정에서는 방문객용 무선랜에서 인터넷으로의 HTTP/HTTPS를 허용하는 규칙(항목 번호 1)과, 방문객용 무선랜에서 서버 네트워크의 DNS로의 접속을 허용하는 규칙(항목 번호 4), 이렇게 두 가지입니다. 아울러 AP 설정에서는 방문객용 SSID 설정을 삭제합니다.

채점 강평은 다음과 같이 적고 있습니다.

문항3(7)은 정답률이 높았다. 방화벽의 모든 필터링 설정과 무선랜 환경 재검토에 따른 영향을 이해하고 답할 필요가 있었으나, 적절히 이해되고 있었다.

정답률이 높았던 문항이지만, 실무에서 여기까지 해내고 있는 조직은 많지 않습니다. 새로운 장치를 도입하는 작업에는 예산도 기한도 붙지만, 오래된 설정을 지우는 작업에는 붙지 않습니다. 그리고 지우는 것을 잊어버리면, 다음과 같은 형태로 표면화됩니다.

이 문제의 방화벽은 항목 번호가 작은 규칙부터 순서대로 평가해, 처음 일치한 규칙을 적용하는 방식입니다(문제문에 그렇게 명기되어 있습니다). 이 방식에서는 더 이상 쓰지 않는 허용 규칙을 위쪽에 남겨 두는 것이, 맨 끝의 거부 규칙에 도달하지 못하게 하는 구멍을 뚫어 놓은 채로 두는 것과 같은 일이 됩니다.

다만 이 평가 방식을 모든 방화벽에 일반화하지 마십시오. 제품에 따라 판정 방식이 다릅니다.

어느 방식이든 쓰지 않는 허용을 남겨 두는 것이 위험하다는 사실 자체는 달라지지 않습니다. 달라지는 것은 ‘왜 위험한가’와 ‘어떻게 고칠 것인가’입니다. 자사 장비가 어느 방식인지 확인한 뒤, 정기 점검 대상에 ‘지금도 발신지·수신지가 존재하는가’라는 관점을 넣으십시오.

업무 앱 쪽에서 필요한 수신 규칙을 어떻게 관리할 것인가라는, 호스트 쪽 방화벽 이야기는 Windows 방화벽과 업무 앱에서 다루고 있습니다.

11. 효과가 없었던 대책과 효과가 있었던 대책

이 문제를 한 장으로 정리하면 다음 표가 됩니다. M사가 갖고 있던 대책과 그것이 어디서 뚫렸는지의 대응입니다.

마지막 한 줄만이 ‘효과가 있었다’입니다. 그리고 대책으로 수립된 것을 나열하면 다음과 같습니다.

비교해 보면 성격의 차이가 뚜렷합니다. 뚫린 대책은 ‘수단’을 금지하는 것이 많고, 효과가 있었던 대책과 수립된 대책은 ‘경로’나 ‘자격 정보의 성질’을 바꾸는 것입니다. USB 메모리를 막아도 파일로의 경로가 남아 있으면 유출은 성립하며, 사전 공유 키를 길게 만들어도 공유 비밀이라는 사실은 변하지 않습니다.

12. 실무 체크 관점

이 문제를 자사의 구성에 적용할 때의 확인 항목을 들겠습니다.

1. 유출 대책을 수단이 아니라 경로로 적어낼 수 있는가. USB 메모리·메일 첨부·웹메일이라는 수단의 목록이 아니라, ‘업무 파일에 도달할 수 있는 단말과 네트워크의 목록’을 만든다. 관리 밖의 단말이 도달할 수 있는 경로가 하나라도 있으면 수단의 금지는 우회된다
2. 반입·반출 규칙이 장소를 한정하고 있지는 않은가. ‘집무실 반입 금지’는 회의실·접수처·공용 공간을 허용하고 있는 것이다. 물리적 구획과 네트워크 구획이 일치하는지 확인한다
3. 발신지 IP 주소 제한이 실제로 허용하고 있는 범위를 말할 수 있는가. 그 글로벌 IP 주소로 나가는 것을 전부 헤아린다. 게스트용 Wi-Fi, 방문객용 네트워크, 거점 간 VPN, 재택근무용 집약 게이트웨이, 검증 환경
4. 무선랜 자격 정보가 단말별로 되어 있는가. 사전 공유 키는 모두가 같은 것을 갖는 공유 비밀이라, 한 사람이 유출하면 전원의 것이 유출되며 특정 한 대만 차단할 수도 없다
5. MAC 주소 필터링과 SSID 비공개를 대책의 수에 포함시키고 있지는 않은가. 둘 다 오접속을 줄이는 정리일 뿐, 인증이 아니다
6. 클라이언트 인증서의 개인 키가 단말에서 꺼낼 수 없는 상태인가. 파일로 둔 개인 키는 복제할 수 있다. TPM을 사용하는 키 저장소 공급자를 지정하고 내보내기를 허용하지 않는다
7. EAP-TLS를 도입한 클라이언트가 인증 서버의 인증서를 검증하고 있는가. 이 부분을 비활성화하면 가짜 인증 서버에 대한 내성이 사라진다
8. 서버 인증서 오류를 사용자가 ‘계속’으로 넘길 수 있는 상태가 되어 있지는 않은가. 자사 사이트에는 HSTS를 설정한다. 사내 시스템의 인증서 오류를 방치해, 사용자에게 ‘오류는 눌러서 넘기는 것’이라고 학습시키지 않는다
9. 신뢰할 수 있는 루트 인증 기관 저장소의 내용을 점검하고 있는가. 그 안에 들어 있는 것은, 그 단말이 ‘이 인증 기관이 발급한 인증서라면 진짜로 간주한다’고 선언하고 있는 상대 그 자체다
10. 승인 워크플로의 승인자에게 판단 근거가 전달되고 있는가. 그리고 승인 결과를 나중에 확인하고 있는가. 사외 도메인 앞·프리메일 앞 공유를 정기적으로 목록으로 확인한다
11. 폐지한 경로의 설정을 지우고 있는가. VLAN 인터페이스, 필터링 규칙, SSID, 허용 목록 항목. ‘새로 넣는’ 작업과 똑같이 취급해, 지우는 작업에도 기한을 붙인다

마치며 ── ‘범위’를 적지 않은 대책은 지키지 못한다

문항1이 ‘그 대책은 어떤 공격의 어느 단계를 막는가’를 묻는 문제였다면, 문항2가 묻는 것은 ‘그 대책은 어디까지 지키는가‘입니다.

M사의 대책에는 모두 암묵적인 범위가 있었습니다. 정보 유출 방지 소프트웨어의 범위는 업무용 PC까지. 반입 금지의 범위는 집무실까지. MAC 주소 필터링의 범위는 ‘위장하지 않는 상대’까지. 발신지 IP 주소 제한의 범위는 ‘그 글로벌 IP 주소로 나가는 모든 사람’까지. 각각의 범위는 올바르게 작동하고 있었지만, 다만 이웃한 것끼리의 이음매가 비어 있었습니다.

이 문제가 실무적인 것은 M사가 성실하게 대책을 세운 회사로 그려지고 있다는 점입니다. 전년도 사건을 겪고 경로의 양 끝을 막았고, 전용 소프트웨어까지 도입했습니다. 그런데도 구멍이 남는 것은 담당자가 게을렀기 때문이 아니라, 대책을 하나씩 더해 가는 방식으로는 범위의 틈이 보이지 않기 때문입니다.

틈을 찾아내려면 대책의 목록이 아니라 경로의 목록을 적을 수밖에 없습니다. 이 문제에서 Y씨와 S씨가 하고 있던 것이 바로 그것입니다. ‘사외 공격자’와 ‘직원’으로 나누고, 각각에 대해 도달 경로를 하나씩 막아 나간다. IPA가 출제 취지에 적은 ‘무선랜을 이용한 환경에서의 위협을 다양한 각도에서 상정하는 능력’이란 바로 이 작업을 말하는 것이겠지요.

관련 상담 영역

합동회사 코무라소프트에서는 기존 네트워크나 단말 구성을 전제로 한 설계 리뷰와, Windows 환경에서의 인증서 배포·키 보호 구현을 다루고 있습니다.

• 기술 상담・설계 리뷰
• Windows 개발
• 결함 조사・원인 분석
• 문의하기

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

USB 메모리 연결을 금지하고 로컬 디스크 저장도 금지했는데, 왜 파일을 유출할 수 있는 건가요?

금지한 것은 회사가 대여한 업무용 PC의 기능이지, 파일이 있는 곳에 도달하는 경로가 아니기 때문입니다. 이 문제에서 직원이 사용하는 것은 자신의 개인 소유 PC입니다. 업무용 PC는 전혀 건드리지 않고, 개인 소유 PC를 회의실의 무선랜에 접속시킨 뒤, 클라우드 스토리지(B서비스)에 자신의 사용자 ID로 로그인해 파일을 다운로드하고, 그 개인 소유 PC를 통째로 가지고 돌아갑니다. 업무용 PC에 넣은 정보 유출 방지 소프트웨어의 설정은 개인 소유 PC에는 전혀 작동하지 않습니다. M사는 개인 소유 PC의 반입을 금지하고 있었지만, 금지 대상은 집무실뿐이었고 회의실은 대상 밖이었습니다. 수단(USB 메모리, 메일 첨부, 웹메일)을 하나씩 막아도, 파일에 도달할 수 있는 경로가 남아 있으면 유출은 성립합니다.

B서비스는 'M사의 글로벌 IP 주소에서만 로그인 가능'하도록 제한하고 있었습니다. 왜 방문객용 무선랜에서 빠져나갈 수 있는 건가요?

방문객용 무선랜의 통신도 같은 방화벽의 NAT를 거쳐 같은 글로벌 IP 주소로 변환된 뒤 인터넷으로 나가기 때문입니다. B서비스 입장에서 보면, 사내 업무용 PC로부터의 접속과 회의실에서 방문객용 무선랜에 연결한 개인 소유 PC로부터의 접속은 둘 다 같은 발신지 IP 주소로 보입니다. 구별할 수 없습니다. 발신지 IP 주소에 의한 제한은 '이 단말에서만'이 아니라 '이 출구를 공유하는 모든 사람'을 허용하는 설정이라고 이해해야 합니다. 게스트용 Wi-Fi, 거점 간 VPN, 재택근무용 집약 게이트웨이 등 같은 글로벌 IP 주소로 나가는 것은 모두 허용 범위에 들어갑니다.

직원용 무선랜에는 MAC 주소 필터링이 걸려 있었습니다. 이것은 대책이 되지 않나요?

되지 않습니다. MAC 주소는 단말 쪽에서 자유롭게 다시 쓸 수 있기 때문입니다. 이 문제의 방법1은 개인 소유 PC의 무선랜 인터페이스 MAC 주소를, 등록된 업무용 PC의 MAC 주소로 변경해 접속하는 것이었습니다. 무선랜 프레임의 MAC 주소는 암호화되지 않은 채 날아다니므로, 근처에서 수신하면 등록된 MAC 주소를 알아낼 수도 있습니다. 같은 이야기가 SSID 비공개에도 적용됩니다. SSID 브로드캐스트를 비활성화해도, 단말이 접속할 때 주고받는 내용에서 SSID가 드러납니다. MAC 주소 필터링과 SSID 비공개는 실수로 잘못 접속하는 사고를 줄이는 효과는 있어도, 의도적인 접속을 막는 인증 장치는 아닙니다.

가짜 액세스 포인트와 가짜 사이트를 준비당해도, 왜 직원은 속지 않는다고 말할 수 있는 건가요?

HTTPS로 접속하는 이상, 가짜 사이트는 서버 인증서 검증을 통과할 수 없기 때문입니다. 문제문의 그림2는 이때 표시될 수 있는 오류의 상세로 4개 항목을 들고 있습니다. 신뢰된 인증 기관이 발급한 것이 아님, 인증서에 적힌 서버명이 접속 대상 서버명과 다름, 실효됨, 유효기간 만료, 이렇게 네 가지입니다. 공격자는 B서비스의 도메인명에 대한 정규 인증서를 입수할 수 없으므로, 자기서명 인증서를 쓰면 첫 번째에서, 자신의 도메인용으로 정규 취득한 인증서를 쓰면 두 번째에서 불합격 처리됩니다. IPA의 채점 강평에 따르면 이 검증 내용을 묻는 문항의 정답률은 낮았다고 합니다. 다만 이 4개 항목이 같은 강도로 작동하는 것은 아닙니다. 공격을 막고 있는 것은 앞의 두 가지(발급자와 이름)와 유효기간이며, 이것들은 브라우저가 반드시 검증합니다. 반면 실효 확인은 구현과 설정에 따라 달라집니다. 예를 들어 Chrome은 온라인 OCSP나 CRL 확인을 평소에는 하지 않고, 긴급 시 차단을 주목적으로 하는 CRLSet이라는 한정된 목록을 사용하는 설계입니다. 실효시키면 반드시 걸러진다고는 생각하지 마십시오. 또한 업무용 PC에 사내 인증 기관의 루트 인증서를 배포해 두었고, 그 인증 기관의 개인 키나 발급 절차를 공격자가 장악하고 있다면, 첫 번째 확인도 통과해 버립니다.

URL을 잘못 입력해 'http://'라고 입력한 경우에는 어떻게 되나요? HSTS는 무엇을 하고 있는 건가요?

브라우저가 HTTP를 HTTPS로 바꾼 뒤 접속하므로, 결과는 마찬가지로 서버 인증서 오류가 됩니다. HSTS는 그 사이트에 이전에 HTTPS로 접속했을 때 받은 헤더 내용을 브라우저가 기억해 두는 구조입니다. RFC 6797은 대상 호스트로의 URL에 http 스킴이 포함된 경우, 사용자 에이전트가 이를 https로 치환할 것, 포트 80이 명시되어 있으면 443으로 변환할 것을 요구하고 있습니다. 즉 평문 HTTP 요청은 네트워크로 나가기 전에 사라집니다. 더 중요한 것은, HSTS가 활성화된 호스트와의 통신에서 인증서 검증에 실패한 경우, 경고이든 치명적이든 접속을 중단할 것이 요구되고 있다는 점입니다. '이 연결은 안전하지 않지만 계속하시겠습니까'와 같은 선택지를 사용자에게 제시해서는 안 된다고 명시되어 있습니다. 다만 HSTS는 그 브라우저가 한 번은 정규 사이트에 HTTPS로 도달해 헤더를 받은 적이 있다는 것이 전제입니다. 완전히 새 단말에서 첫 접속이 처음부터 가짜 사이트였던 경우에는 효과가 없습니다. 이 첫 접속 문제를 메우는 것이 브라우저에 내장된 프리로드 목록입니다.

클라이언트 인증서의 개인 키를 TPM에 저장하면 무엇이 달라지나요?

그 업무용 PC에서 개인 키를 꺼낼 수 없게 됩니다. 파일로 단말에 둔 개인 키는 복사해서 개인 소유 PC로 가져가면, 그 PC가 업무용 PC로서 인증을 통과해 버립니다. TPM 안에서 키를 생성해 내보낼 수 없는 상태로 해 두면, 서명 등의 연산은 TPM 안에서만 이루어지며 키 자체는 OS에도 악성코드에도 넘어가지 않습니다. 결과적으로 EAP-TLS로 인증을 통과할 수 있는 것은 회사가 배포한 업무용 PC뿐이게 됩니다. 이 문제에서 S씨가 '그 저장 방법이라면 문제없다'고 말할 수 있었던 것은 이 때문입니다. Windows에서 구현할 경우에는 인증서 템플릿의 키 저장소 공급자에 Microsoft Platform Crypto Provider를 지정하고, 개인 키 내보내기를 허용하지 않는 설정으로 합니다. 다만 TPM이 지키는 것은 '키가 다른 단말로 복제되지 않는다는 것'뿐이며, 그 단말을 가진 사람이 사용할 수 있다는 사실은 변하지 않습니다. 단말의 분실·도난에 대해서는 드라이브 암호화와 인증서 실효를 별도로 마련해 둘 필요가 있습니다.

이 문제에서 실무로 가져가야 할 것은 무엇인가요?

네 가지가 있습니다. 첫째, 유출 대책은 수단이 아니라 경로로 생각하는 것입니다. USB 메모리, 메일 첨부, 웹메일을 하나씩 막아도 파일에 도달할 수 있는 단말이 남아 있으면 의미가 없습니다. 둘째, 발신지 IP 주소에 의한 제한이 실제로 허용하고 있는 범위를 적어 보는 것입니다. 게스트 Wi-Fi나 VPN이 같은 출구를 쓰고 있다면 그곳도 허용 범위입니다. 셋째, 무선랜 인증을 단말별 자격 정보로 만드는 것입니다. 사전 공유 키는 모두가 같은 것을 갖는 공유 비밀이므로, 한 사람이 유출하면 전원의 것이 유출됩니다. EAP-TLS와 클라이언트 인증서, 그리고 개인 키를 TPM에서 꺼내지 않는 구성으로 만들면 자격 정보가 단말에 고정됩니다. 넷째, 더 이상 쓰지 않는 설정을 지우는 것입니다. 이 문제의 마지막 문항은 방문객용 무선랜을 폐지한 뒤에 남는 VLAN 인터페이스 설정과 방화벽 필터링 규칙을 모두 들게 하는 것으로, IPA의 채점 강평에 따르면 정답률은 높았지만, 실무에서 여기까지 해내고 있는 조직은 많지 않습니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.