앞 회차에서 우리는 정보통신망법 제48조 1항이 "정당한 접근권한 없이 또는 허용된 접근권한을 넘어"라는 조건으로 침입을 처벌한다는 점을 봤습니다. 모의해킹은 이 조항의 정확히 반대편, "허용된 접근권한"의 영역에서 이루어지는 일입니다. 그 "허용"이 무엇으로 만들어지는가, 그것이 이번 회차의 주제입니다.

1. 모의해킹의 법적 정의

한국 법령에 "모의해킹"이라는 단어가 직접 정의되어 있지는 않습니다. 가장 가까운 표현은 「정보통신기반 보호법」과 ISMS-P 인증 기준에 등장하는 "취약점 진단·평가"입니다.

법적으로는 모두 위탁받아 시스템에 침투를 시도하는 행위로 묶입니다. 핵심은 "위탁받아"입니다. 위탁이 없으면 같은 행위가 망법 제48조 위반이 되고, 위탁이 있으면 합법적 보안 활동이 됩니다.

참고 자료: KISA 주요정보통신기반시설 기술적 취약점 분석·평가 상세 가이드

2. 합법과 불법의 갈림길

망법 제48조 1항을 다시 봅니다.

정당한 접근권한 없이 또는 허용된 접근권한을 넘어 정보통신망에 침입하여서는 아니 된다.

이 그림에서 OK 상자에 들어가려면 두 가지가 모두 필요합니다.

1. 권한 부여의 문서화
2. 범위의 명확화

위 두 가지가 보안 실무에서 만들어지는 형태가 바로 계약서, 범위정의서, 승인서입니다.

3. 권한을 만드는 세 가지 문서

위 세 문서는 하나의 흐름에서 각자 다른 역할을 합니다.

세 문서는 보통 같이 만들어집니다. 어느 하나가 빠지면 다른 둘이 무력해지는 경우가 많기 때문입니다.

4. 위탁 계약서

큰 회사는 보통 두 단계로 나눕니다. MSA(Master Service Agreement, 기본계약)에서 양쪽의 일반 의무를 정하고, 개별 프로젝트마다 SOW(Statement of Work, 작업기술서)에서 그 회차의 구체 사항을 정합니다.

4.1 위탁 계약서의 필수 조항

4.2 자주 누락되는 조항들

실무에서 자주 놓치는 조항들이 있습니다. 분쟁이 났을 때 가장 큰 영향을 주는 것들이기도 합니다.

특히 3자 시스템 처리가 중요합니다. 표적 회사의 시스템이 AWS·GCP에 있으면, 그 모의해킹은 클라우드 사업자의 사전 승인도 필요한 경우가 많습니다(AWS는 일부 서비스에 사전 신고 의무를 폐지했지만, 부하 테스트는 여전히 별도 양식 필요). 계약서에 "3자 시스템에 대한 별도 승인 절차"가 들어 있어야 합니다.

참고 자료: AWS Customer Support Policy for Penetration Testing (AWS 공식)

5. 범위정의서

범위정의서는 위탁 계약서를 기술적인 언어로 풀어쓴 문서입니다. 어디까지가 표적이고 어디부터가 표적이 아닌지를 한 줄도 모호하지 않게 적습니다.

5.1 In-Scope와 Out-of-Scope

In-Scope만 적고 Out-of-Scope를 빼는 것은 위험합니다. 비슷한 도메인이지만 운영팀이 다른 시스템, 외주사가 운영하는 결제 시스템, 이런 자리들은 명시적으로 빼야 분쟁이 안 납니다.

5.2 사용 도구·기법의 정의

같은 SQL 인젝션이라도 어떤 도구로, 어떤 페이로드로 시도하느냐에 따라 위험도가 다릅니다. 범위정의서는 이 부분도 다룹니다.

DoS·사회공학·물리 침투는 별도 합의가 없는 한 금지하는 것이 표준입니다. 5장에서 봤듯 DoS는 망법 제48조 2항(5년/5천만)에 직결되고, 사회공학은 통신비밀보호법·근로기준법 영역까지 건드릴 수 있습니다.

5.3 시간·인원·통신 채널

수행 인원과 점검자 IP를 사전에 화이트리스팅해 두는 것이 중요합니다. 이게 없으면 SOC가 모의해킹 트래픽을 실제 공격으로 오인해 사이버수사대에 신고하는 사고가 종종 일어납니다. 같은 회사 안에서도 보안운영팀과 모의해킹팀이 분리되어 있으면 이 절차가 필요합니다.

6. 승인서

승인서는 짧고 강력합니다. 위탁 계약서와 범위정의서가 있어도, 분쟁이 났을 때 "이 행위가 정말 승인된 것인가"를 한 장으로 입증해 줄 종이가 별도로 필요합니다. 모의해킹팀 입장에서는 망법 제48조 위반 항변의 가장 직접적인 증거가 되고, 발주사 입장에서는 외부 인력에게 자기 자산을 만질 권한을 부여한 사실을 사내·외부에 공식 표명하는 문서입니다.

6.1 승인서의 기본 양식 (한국 법인 표준)

한국 법인 간 문서로 인정받으려면 개인 서명만으로는 약합니다. 법인 인감(직인), 사업자등록번호, 갑·을 표기가 들어가야 한국 계약서의 일반 형식과 맞습니다. 다음은 8.1절 시나리오(위니브쇼핑몰 ↔ 페네트레이션랩)에 맞춘 예시입니다.

[모의해킹 수행 승인서 / Authorization Letter for Penetration Testing]

위탁자(이하 "갑")
  - 법인명: 위니브쇼핑몰 주식회사
  - 사업자등록번호: 123-45-67890
  - 본점 소재지: 서울특별시 강남구 ○○로 ○○
  - 대표이사: 홍길동
  - 정보보호최고책임자(CISO): 김영수

수탁자(이하 "을")
  - 법인명: 페네트레이션랩 주식회사
  - 사업자등록번호: 987-65-43210
  - 본점 소재지: 서울특별시 마포구 ○○로 ○○
  - 대표이사: 이수진

본 문서는 갑이 을에게 아래 범위 내에서 모의해킹(취약점 진단)을
수행하도록 정식 승인되었음을 확인합니다.

1. 승인 대상
   - 시스템: 첨부 「범위정의서 v1.0」의 In-Scope 목록
   - 기간: 2026년 06월 01일 09:00 ~ 2026년 06월 12일 18:00 (KST)
   - 수행 인원: 첨부 「수행 인원 명단」의 3명

2. 승인 권한 및 법적 근거
   본 승인은 갑의 정보보호최고책임자 권한(정보통신망법 제45조의3)
   에 따라 발행되며, 본 승인서 범위 내 을의 접근·테스트 행위는
   「정보통신망법」 제48조 제1항의 "허용된 접근권한"에 해당함을
   갑이 확인합니다.

3. 개인정보 처리 (해당 시)
   본 점검 과정에서 개인정보에 접근할 가능성이 있는 경우,
   별도 체결한 「개인정보 처리위탁 계약」(개인정보보호법 제26조)
   의 통제를 따르며, 본 승인서는 동 계약과 함께 효력을 가집니다.

4. 비상 연락
   본 활동에 관한 의문이 있을 경우 즉시 아래로 연락 바랍니다.
   - 갑 CISO: 김영수, 010-XXXX-XXXX
   - 갑 24시간 보안운영센터(SOC): 02-XXXX-XXXX
   - 을 점검 책임자: 박철호, 010-XXXX-XXXX

[작성일] 2026년 5월 28일

위탁자(갑): 위니브쇼핑몰 주식회사
            대표이사 홍길동                (법인 인감)
            정보보호최고책임자 김영수      (서명)

수탁자(을): 페네트레이션랩 주식회사
            대표이사 이수진                (법인 인감)

[첨부]
  1. 범위정의서 v1.0
  2. 수행 인원 명단 (신분증 사본 포함)
  3. 갑·을 법인 인감증명서 각 1부
  4. 개인정보 처리위탁 계약서 (해당 시)

6.2 승인서를 강력하게 만드는 요소

물리적 사본 휴대가 의외로 중요합니다. 점검 중 발주사 SOC가 트래픽을 실제 공격으로 오인해 출동하거나 사이버수사대에 신고하는 사고가 종종 있는데, 이때 점검자가 노트북을 압수당하기 전에 "이것이 승인된 활동임"을 즉시 보여줄 수 있어야 합니다. 이메일로 받은 PDF는 노트북이 묶이는 순간 함께 차단되므로, 종이 사본을 신분증과 함께 휴대하는 것이 표준 절차입니다.

6.3 개인정보가 걸릴 때: PIPA 제26조 처리위탁 계약

모의해킹 중 개인정보에 접근할 가능성이 조금이라도 있다면, 승인서 한 장으로 끝나지 않습니다. 개인정보보호법 제26조에 따른 처리위탁 계약이 별도로 체결되어야 합니다. 두 문서가 답하는 질문이 다릅니다.

이 계약 없이 모의해킹 중 개인정보를 마주치면 갑·을 모두 PIPA 위반 책임에서 자유롭지 않습니다. "추출 가능 여부만 확인하고 실제 데이터는 안 봤다"는 항변도 약합니다. 가능 여부를 검증하는 순간 일시적으로라도 개인정보에 접근하기 때문입니다. 안전한 쪽은 점검 시작 전 처리위탁 계약을 미리 체결하고, 그 사실을 승인서 3항에서 인용해 두는 것입니다.

참고 기사: 위탁자라면 반드시 알아야 할 개인정보 처리위탁 (보안뉴스 칼럼)

7. 무단 침투 vs 허가된 테스트: 사례 분석

같은 행위가 종이 한 장의 차이로 어떻게 갈리는지를 사례로 보겠습니다.

7.1 사례 1: 친구 사이트 "도와주려고" 점검

상황: 친한 친구가 운영하는 작은 쇼핑몰의 보안이 걱정돼서, 친구에게 "보안 한번 봐줄게"라고 카톡으로 동의를 받고 SQL 인젝션을 시도했다. 취약점을 찾아 친구에게 알려줬다.

대표가 1인이면 본인 동의로 갈음 가능하지만, 사후 분쟁 시 입증 자료가 빈약합니다. 카카오톡은 사후 삭제·편집이 가능해 증거능력이 약하기 때문입니다. 같은 일을 메일 + 간단한 승인서로 남겨야 합니다.

7.2 사례 2: 사내 모의해킹 중 외주사 시스템 발견

상황: 회사 모의해킹 중 사내 시스템을 점검하다 외주사가 운영하는 연동 API 서버를 발견. "어차피 우리 회사 자산이니까"라며 같이 점검했다.

외주사가 운영하는 시스템은 외주사의 동의가 별도로 필요합니다. 같은 회사가 비용을 내고 있어도 자산 책임이 외주사에 있으면 별도 절차가 작동합니다.

7.3 사례 3: 버그 바운티 프로그램 범위 외 발견

상황: 공식 버그 바운티 프로그램에 등록된 범위(*.example.com)를 점검하던 중, 같은 회사가 운영하는 다른 도메인(internal-tool.example-corp.com)에서 더 큰 취약점을 발견. 추가 보고를 위해 그쪽도 좀 더 들여다봤다.

이런 상황에서 올바른 절차는 추가 점검을 멈추고, 발견 사실을 프로그램 운영자에게 보고하면서 "범위 외이지만 우연히 본 것"이라고 명시하는 것입니다. 일부 프로그램은 이런 보고도 보상하지만, 자기 판단으로 점검을 더 해버리면 보상 거절 + 법적 책임으로 이어집니다.

7.4 사례 4: 모의해킹 중 운영 데이터 추출

상황: SQL 인젝션이 성공해 회원 테이블 전체를 추출했다. 보고서에 "100만 건 추출 가능 확인"이라고 적기 위해 데이터를 모의해킹팀 노트북에 저장했다.

올바른 절차는 다음과 같습니다.

1. 추출 가능성을 건수만 확인하고 데이터는 노트북에 저장하지 않음
2. 부득이 저장 시 즉시 암호화, 점검 종료 시 안전 폐기
3. 보고서에는 샘플 1~2건을 마스킹 처리해 첨부
4. 폐기 절차를 폐기 확인서로 남겨 발주사에 제출

8. 모의해킹 계약서 초안 작성 실습

이번 회차의 마무리는 모의해킹 위탁 계약서 한 부를 직접 초안 잡아 보는 일입니다. 앞 절들에서 본 위반·회색지대 사례들을 종이 위에서 막아 내는 작업이라고 보면 됩니다.

8.1 과제

발주사는 OOO 서비스(가칭) 라는 국내 사업자, 수탁사는 본인이 속한 정보보안 회사라고 가정합니다. 발주사의 업종·규모·점검 동기(ISMS-P 갱신, 신규 서비스 출시 전 사전 점검, 침해사고 후속 점검 등)는 본인이 자유롭게 설정합니다.

다음 조건을 모두 만족하는 모의해킹 위탁 계약서 초안 1부와 별첨 문서 일체를 작성하세요.

• 계약서 본문은 단일 문서로 한국어로 작성하되, 별첨(작업기술서, NDA, 보안서약서, 비상연락망)은 본문에서 인용만 하고 별도 문서로 정리합니다.
• 본 챕터 1장~7장에서 본 위험을 모두 회피할 수 있도록 조항을 설계합니다. 특히 7장 사례 4개(친구 사이트, 외주사 시스템, 범위 외 발견, 운영 데이터 추출)에서 문제가 됐던 빈틈이 본인이 쓴 계약서에서는 어떻게 닫히는지 자가 점검할 수 있어야 합니다.
• 정보통신망법 제48조, 개인정보보호법 제26조·제29조, 신용정보법(해당 시), 산업기술보호법(기술자료가 포함될 경우)의 적용 관계를 본문 또는 전문(前文)에서 정리합니다.
• 분량은 본문 기준 A4 5~10쪽 내외를 권장합니다. 너무 짧으면 빠지는 항목이 생기고, 너무 길면 실제 협상에서 통과되지 않습니다.

8.2 작성 시 반영할 한국 실무 포인트

조항을 설계할 때 다음 한국 관행과 법령 환경을 고려합니다. 외국계 템플릿을 그대로 번역하면 어긋나는 지점들입니다.

• 표준계약서 참고: KISA가 공개하는 정보보호 컨설팅 분야 표준계약서, 조달청 SW사업 표준계약서를 출발점으로 삼습니다. 처음부터 백지에서 쓰는 것이 아니라 표준안의 조항 구조를 가져와 모의해킹 특성에 맞게 변형하는 방식이 일반적입니다.
• 처리위탁과의 관계: 모의해킹 위탁 계약은 PIPA 제26조의 처리위탁 계약과 다릅니다. 개인정보에 접근할 가능성이 있다면 별도의 처리위탁 계약을 함께 체결하고, 본 계약서에서는 그 사실을 인용합니다(6.3 참고).
• 양벌규정과 관리감독 의무: 발주사·수탁사 모두 임직원의 위반에 대해 양벌규정이 적용됩니다. 양 당사자가 서로의 관리감독 의무 이행을 어떤 자료로 입증할지(투입 인력 명단, 보안서약서, 교육 이수증 등)를 명문화합니다.
• 정보보호 배상책임보험: 일정 규모 이상의 정보통신서비스 제공자는 정보보호 배상책임보험 가입이 의무입니다. 수탁사 측에도 자체 배상책임보험 가입 증빙을 요구하는 것이 일반적이며, 보험증권 사본을 별첨으로 받습니다.
• 영업일·점검 시간대: 한국은 주말·공휴일 점검에 대한 추가 비용 산정이 관행이며, 운영 영향이 큰 점검(부하·DoS·사회공학)은 야간 또는 주말로 한정합니다. 점검 시간대를 명시하지 않으면 영업시간 중 장애 책임 분쟁이 발생합니다.
• 대금 지급 구조: 선금 30% / 중간보고 후 30% / 최종 산출물 인수 후 잔금 40% 같은 분할 지급이 일반적이며, 부가세는 반드시 "별도" 표기를 합니다. 세금계산서 발행 시점도 명시합니다.
• 인력 자격과 신원: 투입 인력의 경력·자격(정보보안기사, CPPG, OSCP 등)을 별첨으로 제출받고, 변경 시 사전 통지·승인을 의무화합니다. 외국인 점검자가 포함될 경우 데이터 국외 이전 이슈가 생기므로 주의합니다.
• 언어와 준거법: 양 당사자가 모두 한국 법인이라면 한국어 정본·한국법 준거를 명시합니다. 영문본을 함께 작성할 경우 어느 쪽이 정본인지 못 박습니다.
• 분쟁 해결: 관할 법원은 통상 발주사 본점 소재지를 1심으로 합의합니다. 대한상사중재원 중재 조항을 넣는 경우도 있는데, 보안 분쟁 특성상 비공개 진행이 가능한 중재가 유리할 수 있습니다.

참고 자료: 정보보호서비스 표준계약서 (정보보호산업진흥포털)

9. 사내 모의해킹 vs 외부 위탁 모의해킹

같은 모의해킹이라도 누가 수행하느냐에 따라 절차가 다릅니다.

사내 모의해킹은 비용·기밀 면에서 유리하지만 객관성이 약합니다. 같은 시스템을 만든 동료가 점검하면 같은 가정에 같은 사각지대를 가질 가능성이 높기 때문입니다. ISMS-P 등 인증 갱신 시에는 외부 위탁이 사실상 필수에 가깝습니다.

10. 모의해킹 중 발견되는 "예상 외" 자산

가장 어려운 자리입니다. 점검 중 In-Scope에 적힌 적 없는 자산이 우연히 발견되는 일이 자주 있습니다.

10.1 발견되는 자산의 유형

10.2 대응 절차

가장 중요한 원칙은 혼자 판단하지 않는 것입니다. "어차피 같은 회사인 것 같으니 좀 더 봐도 되겠지"라는 판단이 7.2 사례의 위반으로 이어집니다.

10.3 침해 흔적 발견 시

점검 중 이미 누군가 침투한 흔적(백도어, 외부 통신 채널, 기존 위협행위자의 도구)을 발견하면 절차가 더 까다롭습니다.

이 자리를 모르고 계속 점검하면, 자기 활동이 기존 침입자의 흔적을 덮어버리는 사고로 이어집니다. 증거가 사라지면 49조 비밀 침해의 최초 침입자를 추적할 수 없게 되고, 그 책임이 모의해킹팀에 돌아옵니다.