남의 사이트를 원격 스캔하지 않는 이유: 자가진단 CLI 설계

요약: 웹사이트 취약점 자가진단 도구를 만들면서 "URL을 넣으면 외부에서 스캔해 주는 서비스" 대신 "서버 안에서 직접 실행하는 CLI"를 택했다. 소유자 확인이 어렵고, 권한 없는 접근으로 해석될 여지가 있어 정보통신망법 위험을 떠안게 되기 때문이다. 어떤 조항이 문제인지와, 로컬 실행이 그 위험을 구조적으로 없애는 과정을 정리한다.

처음 떠올린 구조: URL 넣으면 검사해 주는 서비스

취약점 자가진단 도구를 만든다고 하면 가장 먼저 떠오르는 모양이 있다. 웹 화면에 도메인을 입력하면 서버가 그 사이트에 접속해 헤더, 노출된 파일, 오래된 버전 같은 것을 검사하고 리포트를 돌려주는 방식이다. 사용자는 아무것도 설치하지 않아도 되니 편하다.

그런데 이 구조에는 근본적인 문제가 하나 있다. 입력한 도메인이 정말 그 사람의 것인지 알 수 없다.

• 입력창에는 누구든 아무 도메인이나 넣을 수 있다.
• 소유자 확인(DNS TXT 레코드, 파일 업로드 등)을 붙여도 우회와 오용 가능성을 완전히 없애기는 어렵다.
• 요청은 내 서비스의 서버에서 대상 서버로 나간다. 접근의 주체가 도구 제공자가 되는 것이다.

정보통신망법이 문제 삼는 지점

한국에서 이 구조가 부딪히는 대표 조항은 정보통신망법 제48조다.

여기에 스캔이 대상 서버를 느리게 하거나 멈추게 하면 형법의 업무방해(제314조) 쟁점이 따라올 수 있다.

핵심은 "정당한 접근권한"이다. 취약점 스캔은 원래 대상 시스템에 비정상적인 요청을 보내 반응을 보는 행위다. 소유자가 요청했다면 점검이고, 그렇지 않다면 침입 시도로 해석될 여지가 생긴다. 도구가 같은 요청을 보내도 누가, 누구의 동의를 받고 실행했는가에 따라 평가가 갈린다.

그리고 원격 스캔 서비스에서는 이 위험이 사용자에게만 있지 않다. 남의 사이트에 요청을 실제로 보내는 쪽은 서비스 서버이므로, 악용 사례가 생기면 도구 제공자도 책임 논란에서 자유롭지 않다.

선택: 서버 안에서만 도는 CLI

그래서 구조를 뒤집었다. 도구를 웹 서비스가 아니라 점검 대상 서버에 직접 올려 실행하는 CLI로 만들었다.

# 점검할 서버에 접속한 뒤, 그 서버 안에서 실행한다
php bin/diagnose scan --path /var/www/myapp

이렇게 하면 소유자 확인 문제가 코드가 아니라 구조로 해결된다.

• CLI를 실행하려면 그 서버에 로그인할 수 있어야 한다. 서버에 접근할 권한이 있는 사람만 실행할 수 있다.
• 점검은 서버 안의 설정과 파일을 읽는 방식이라, 다른 서버로 요청을 보내지 않는다.
• 결과는 터미널에만 출력하고 외부로 전송하지 않는다.
• 남의 사이트 주소를 넣을 입력 자체가 없으므로, 남의 사이트에는 쓸 수 없다.

무엇이 달라지는가

원격 방식에서는 "이 사용자가 정말 소유자인가"를 소프트웨어가 계속 의심해야 한다. 로컬 CLI에서는 그 질문이 사라진다. 서버에 들어갈 수 있다는 사실이 곧 소유자(또는 소유자가 허락한 운영자)라는 증거이기 때문이다.

치르는 대가도 있다.

• 사용자가 직접 서버에 설치하고 실행해야 해서 "URL만 넣으면 끝"보다 번거롭다.
• 외부에서 보이는 공격 표면(열린 포트, 외부 노출 상태)은 서버 안에서 완전히 볼 수 없다. 이 한계는 문서에 분명히 적는다.
• 서버 안에서 실행되므로 도구 자체가 신뢰할 수 있는 코드여야 한다. 오픈소스로 공개해 읽어 볼 수 있게 하는 편이 맞다.

배운 점

• 보안 도구에서는 기능만큼 실행 주체가 누구인가가 설계의 핵심이다. 같은 요청도 소유자가 보내면 점검, 아니면 침입으로 읽힐 수 있다.
• 소유자 확인을 코드로 구현하는 것보다, 소유자만 실행할 수 있는 구조로 만드는 편이 단순하고 우회하기 어렵다.
• "편리한 웹 서비스"가 법적·윤리적 위험을 키운다면, 불편하더라도 위험이 구조적으로 없는 쪽을 먼저 고려한다.
• 이 글은 법률 자문이 아니다. 비슷한 도구를 만든다면 서비스 형태를 정하기 전에 전문가 검토를 받는 것이 안전하다.