합동회사 코무라소프트
日本語 English 한국어 繁體中文 العربية
문의하기
메뉴

왜 이메일 보안에서 PPAP는 안 되는가. 올바른 방법은?

· · 이메일 보안, PPAP, 정보 유출 대책, B2B, 기존 자산 활용

「비밀번호가 붙은 ZIP을 보내고, 그 후에 별도의 메일로 비밀번호를 보내는 운용은 정말 안전한가」. 이 질문은 지금도 자주 나옵니다. 겉으로 보면 암호화되어 있으므로 안전해 보이지만, 실무에서는 여기가 함정입니다.

먼저 결론을 말하자면, 이른바 PPAP는 도청 대책으로서 약하고, 오송신 대책으로도 불충분하며, 더욱이 메일 경로상의 검사를 방해하기 쉬우므로 현재의 메일 보안에서는 권하기 어려운 방식입니다.1234

이 글에서는 2026년 4월 시점에서 확인할 수 있는 공적 자료와 1차 정보를 바탕으로, PPAP의 문제점과 실무에서 어떻게 교체하는 것이 자연스러운지를 정리합니다.12536748910

1. 먼저 결론

PPAP를 그만두는 이야기는 암호화를 그만두는 이야기가 아닙니다. 그만두어야 할 것은 「첨부 파일을 ZIP으로 암호화하고, 같은 메일 계통으로 나중에 비밀번호를 보낸다」는 설계입니다.

대신 생각해야 할 것은 다음 3가지입니다.

  1. 통상의 업무 메일은 TLS / STARTTLS 같은 통신 경로 보호를 전제로 한다.710
  2. 메일 자체의 진정성이나 암호화가 필요하다면 S/MIME 같은 구조를 쓴다.536
  3. 기밀 파일의 수수는 첨부가 아니라 인증 부착 다운로드나 접근 제어가 붙은 공유로 옮긴다.489

요컨대, 메일의 문제를 ZIP의 비밀번호로 전부 해결하려고 하지 않는 것이 중요합니다.

2. 애초에 PPAP란 무엇인가

여기서 말하는 PPAP는 일반적으로 다음 흐름을 가리킵니다.

  1. 파일을 비밀번호가 걸린 ZIP으로 만든다
  2. 첫 번째 메일에서 ZIP을 보낸다
  3. 두 번째 메일에서 비밀번호를 보낸다

이 운용은 「평문으로 보내고 있지 않으니 안전하다」고 이해되기 쉽습니다. 하지만 실제로 지켜지는 범위는 상당히 한정적입니다.

관점 PPAP로 충분한가 실제 평가
통신 경로상의 비밀성 약함 같은 메일 계통으로 별송하면 효과가 옅다
오송신 대책 불충분 수신자를 잘못 지정한 시점에 사고가 성립되기 쉽다
멀웨어 대책 오히려 불리 경로상 검사를 방해하기 쉽다
발신자의 진정성 지킬 수 없음 사칭 대책이 아니다
접근 제어 지킬 수 없음 누가 열람 가능한가의 제어가 약하다

보이는 것만큼 만능이 아니며, 「왠지 안전해 보인다」에 비해 핵심 부분을 지키지 못하고 있다는 것이 PPAP의 문제입니다.

3. 왜 PPAP는 안 되는가

3.1 도청 대책으로서 약하다

내각부는 ZIP 파일 송부와 같은 경로로 비밀번호를 자동 송신하는 방식은 적절하지 않다고 정리하고 있습니다.1 중요한 것은, 파일을 암호화했는지 여부만이 아니라, 키를 어떻게 전달할지까지 포함해서 설계하지 않으면 의미가 옅어진다는 점입니다.

같은 메일 환경, 같은 받은편지함, 같은 상대에게 뒤이어 보내기만 해서는 ZIP을 볼 수 있는 사람과 비밀번호를 볼 수 있는 사람이 거의 같아지기 쉽기 때문입니다. 이것으로는 「암호화하고 있다」는 사실만 남고, 실질적인 비밀성은 그다지 강하지 않습니다.

3.2 오송신 대책으로 불충분

PPAP를 오송신 대책으로 생각하는 운용도 있지만, 그곳도 약합니다.

IPA의 응용정보기술자 시험 해답 예에서는 PPAP의 문제점으로, 본문 메일을 잘못 송신하면 복호화용 비밀번호도 잘못된 상대에게 도달해 버리는 점이 지적되고 있습니다.3 디지털청의 자료에서도 「별도 메일로 상대방에게 보내는 것은 같은 상대에게 보내게 되어, 컨트롤로서 기능하지 않는다」는 취지의 정리가 제시되어 있습니다.4

즉, 잘못된 상대에게 ZIP을 보낸 후 습관적으로 비밀번호도 계속 보내 버리면 사고는 그대로 완성된다는 이야기입니다. 정말로 필요한 것은 수신자 확인, 승인, 송신 전 리뷰, 송신 후의 실효나 회수가 가능한 수수 방식입니다.

3.3 멀웨어 검사를 방해한다

이것은 PPAP 중에서도 상당히 중요합니다.

IPA는 비밀번호가 걸린 ZIP을 첨부한 Emotet 공격 메일에 대해, 첨부 파일이 암호화되어 있으므로 메일 배송 경로상의 보안 제품의 검지·검역을 빠져나가 수신자의 손에 도달할 확률이 높다고 주의 환기를 하고 있습니다.2

송신 측은 「암호화하여 안전하게 했다고 생각하고」 있어도, 수신 측이나 중계 측에서 보면 내용을 검사하기 어려운 첨부 파일이 되어 버립니다. 이 점에서도 PPAP는 현재의 메일 방어와 궁합이 좋은 방식이라고는 할 수 없습니다.

3.4 진정성과 접근 제어를 담보하지 않는다

PPAP는 발신자가 진짜임을 증명하지 않습니다. 또한 누가 언제 다운로드했는지, 나중에 실효할 수 있는지, 상대별로 권한을 나눌 수 있는지와 같은 접근 제어도 거의 가지고 있지 않습니다.

한편, IPA는 S/MIME 같은 전자 서명이 붙은 메일을 다루고 있으며, PPAP의 대체로서도 문맥상 이어져 있습니다.56 또한 IPA의 웹 보안 자료에서는 비공개 정보를 다루는 웹에는 인증 기능과 접근 제어가 필요하다고 정리되어 있습니다.8

이 2가지를 합쳐서 생각하면 답은 꽤 명확합니다.

  • 메일의 진정성이나 변조 검지가 필요하다면 S/MIME
  • 파일의 열람 권한이나 실효 관리가 필요하다면 인증 부착 다운로드

ZIP의 비밀번호 별송은 그 어느 쪽에도 깔끔하게 답하고 있지 않습니다.

4. 올바른 방법은 「목적별로 나누는 것」

「안전하게 보내고 싶다」라는 요구는 실제로는 하나가 아닙니다. 여기를 나누지 않고 전부 PPAP로 끝내려고 하면 설계가 무너집니다.

4.1 통상의 업무 메일

통상의 업무 메일이라면, 우선은 TLS / STARTTLS 같은 통신 경로 보호가 전제입니다.710 그 위에서 발신자의 진정성, 변조 검지, 메일 본문 자체의 암호화가 필요하다면 S/MIME를 검토하는 것이 순서입니다.536

4.2 기밀 파일의 수수

상대 본인에게만 파일을 건네고 싶다, 열람 권한을 제어하고 싶다, 나중에 실효하고 싶다. 이 요건이라면 첨부보다 인증 부착 다운로드나 접근 제어가 붙은 공유가 더 자연스럽습니다.489

예를 들어 다음과 같은 요건은 첨부보다 웹 쪽에서 관리하는 편이 다루기 쉬워집니다.

  • 로그인 후에 다운로드할 수 있다
  • 기간 한정 링크로 할 수 있다
  • 상대별로 권한을 나눌 수 있다
  • 필요하다면 이력을 남길 수 있다

4.3 아무래도 첨부가 필요한 경우

상대의 사정으로 아무래도 첨부밖에 쓸 수 없는 장면은 있습니다. 그 경우는, 내각부의 정리에도 있는 것처럼, 파일과 비밀번호를 완전히 다른 경로로 전달하는 것이 최소한의 선이 됩니다.1

다만 이것은 완성형이 아니라 잠정책입니다. 매번의 표준 운용으로 고정하기보다는, 장래적으로는 인증 부착 공유로 옮기는 전제로 생각하는 편이 좋습니다.

5. 중소기업에서의 치환 절차

중소기업에서 PPAP를 그만둘 때는 처음부터 큰 구조를 도입하기보다, 우선 분류를 명확히 하는 편이 효과적입니다.

5.1 먼저 그만둘 것

  • 자동 ZIP 암호화
  • 같은 메일 계통에서의 자동 비밀번호 별송
  • 「중요 파일은 전부 PPAP」라는 일률적 규칙

5.2 다음으로 결정할 것

  • 무엇을 통상 메일로 보내도 좋은가
  • 무엇을 첨부 금지로 할까
  • 무엇을 인증 부착 다운로드로 돌릴까
  • 예외적으로 첨부할 경우의 승인 절차를 어떻게 할까

5.3 최소 구성의 생각법

처음에는 다음 2 계통으로 나누기만 해도 충분합니다.

  1. 통상 메일
    • 업무 연락
    • 필요에 따라 S/MIME
  2. 기밀 파일
    • 인증 부착 다운로드
    • 권한 설정
    • 기간 한정 공유

여기가 애매하면 현장은 결국 「일단 PPAP」로 돌아가기 쉬워집니다.

6. 판단 플로우

flowchart TD
    A[상대에게 무엇을 건네고 싶은가] --> B{기밀성이 높은 파일인가}
    B -- 아니오 --> C[통상의 업무 메일]
    C --> C1[TLS / STARTTLS를 전제로 보낸다]
    C --> C2[진정성이나 암호화가 중요하다면 S/MIME]

    B -- 예 --> D{상대가 로그인하여 받을 수 있는가}
    D -- 예 --> E[인증 부착 다운로드 / 접근 제어가 붙은 공유]
    E --> E1[필요에 따라 권한·기한·실효를 설정]

    D -- 아니오 --> F{아무래도 첨부가 필요한가}
    F -- 예 --> G[암호화 파일 + 별경로의 수동 비밀번호]
    F -- 아니오 --> E

이 그림에서 중요한 것은 PPAP를 만능의 중간해로 놓지 않는 것입니다. 메일과 파일 수수는 나누어 생각하는 편이 설계하기 쉬워집니다.

7. 자주 있는 오해

7.1 「ZIP을 암호화하고 있으니까 안전」

암호화하고 있어도, 키의 전달 방식이 약하면 충분하지 않습니다. 게다가 비밀번호가 걸린 ZIP은 경로상 검사를 방해하는 경우가 있습니다.12

7.2 「별도 메일로 보내면 충분」

같은 상대, 같은 메일 계통으로의 뒤이은 송신으로는 강한 컨트롤이 되지 않습니다.14

7.3 「PPAP를 그만두면 첨부할 수 없게 된다」

그렇지 않습니다. 통상 메일, S/MIME, 인증 부착 다운로드, 예외 시의 별경로 비밀번호를 구분해서 쓰기만 하면 됩니다.

7.4 「S/MIME는 대기업용이고 현실적이지 않다」

상대 측의 대응 상황은 봐야 하지만, 적어도 PPAP보다는 무엇을 지키고 싶은가에 대한 논리가 통합니다. 또한 S/MIME가 맞지 않는 상대에게는 인증 부착 다운로드라는 별도의 선택지가 있습니다.

8. 정리

PPAP가 안 되는 것은 암호화하고 있는데 안전해진 기분이 들기 쉬운 점에 있습니다. 실제로는,

  • 같은 메일 계통에서의 별송은 비밀성이 약하다
  • 오송신 대책으로 불충분
  • 비밀번호가 걸린 ZIP은 경로상 검사를 방해한다
  • 발신자의 진정성이나 접근 제어는 담보할 수 없다

라는 문제가 남습니다.1234

따라서 해야 할 것은 PPAP풍 운용을 조금 바꿔서 연명하는 것이 아닙니다. 메일은 메일로 지키고, 파일 수수는 파일 수수로 설계하는 것입니다.

한마디로 정리하면 이렇습니다.

PPAP를 그만두는 것은 암호화를 그만두는 것이 아니라, 잘못된 컨트롤을 그만두고, 목적에 맞는 컨트롤로 바꾸는 것입니다.

관련 글

참고 자료

  1. 내각부, 히라이 내각부 특명 담당 대신 기자회견 요지 2020년 11월 24일 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  2. IPA, 상담 급증／비밀번호가 붙은 ZIP 파일을 사용한 공격 사례(2020년 9월 2일) ↩ ↩2 ↩3 ↩4 ↩5

  3. IPA, 레이와 5년도 가을 응용정보기술자 시험 해답 예 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  4. 디지털청, 디지털 개혁을 향한 멀티 스테이크홀더 모델의 운용(처분 통지 등의 디지털화)·의견 개요 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  5. IPA, 레이와 5년도 가을 응용정보기술자 시험 채점 강평 ↩ ↩2 ↩3 ↩4

  6. IPA, 전자 서명에 대하여 ↩ ↩2 ↩3 ↩4

  7. IPA, 중소기업의 정보 보안 대책 가이드라인 제4.0판 ↩ ↩2 ↩3

  8. IPA, 안전한 웹사이트 만드는 법 - 1.11 접근 제어나 인가 제어의 결락 ↩ ↩2 ↩3 ↩4

  9. NIST, Security Considerations for Exchanging Files Over the Internet ↩ ↩2 ↩3

  10. IPA, CPG(CISA Cross-Sector Cybersecurity Performance Goals) 일본어판 ↩ ↩2 ↩3

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

저자 프로필

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

Go Komura

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

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

문의하기
블로그 목록으로 돌아가기