모두
모두콘텐츠
얼마 전 작은 쇼핑몰의 보안 점검을 도왔는데, 담당자가 가장 먼저 보여준 건 서버 사양표였다. 방문자는 하루 2천 명 정도였고 서버 자원도 넉넉했다. 그런데 백업 파일이 같은 서버에 쌓여 있었고, 관리자 계정은 퇴사자에게 발급한 것까지 살아 있었다. 이런 사이트는 서버를 키워도 안전해지지 않는다. 모의해킹을 준비할 때 먼저 볼 곳도 대개 이쪽이다.
모의해킹은 허가받은 범위에서 실제 공격자가 찾을 법한 약점을 확인하는 작업이다. 취약점 검사 도구를 한 번 돌리는 것과는 다르다. 발견한 문제가 어떤 권한과 데이터에 영향을 주는지 확인하고, 수정한 뒤 다시 점검해야 운영에 쓸 수 있는 결과가 된다. 반대로 범위를 정하지 않고 운영 서버에 강한 검사를 걸면 점검 자체가 장애 원인이 될 수 있다.
점검 범위와 중단 기준부터 적는다
시작 전에는 대상 서버, 애플리케이션, 관리자 화면, API, 테스트 계정을 문서에 적는다. 같은 회사가 운영해도 결제창이나 외부 인증 서비스는 다른 사업자의 영역일 수 있다. 도메인을 갖고 있다는 이유만으로 연결된 모든 서비스를 시험해도 된다는 뜻은 아니다. 공유 웹호스팅이라면 호스팅 업체의 허용 범위도 확인해야 한다. 한 고객의 점검 트래픽이 같은 장비의 다른 고객에게 영향을 줄 수 있기 때문이다.
운영 환경을 직접 점검한다면 시간과 강도를 제한한다. 예를 들어 방문이 적은 새벽 두 시간으로 창을 잡고, 초당 요청 수와 동시 연결 수의 상한을 정한다. 오류율이 평소보다 높아지거나 응답 시간이 급격히 늘면 즉시 멈춘다는 기준도 필요하다. 로그인 실패가 쌓여 정상 사용자의 계정이 잠기는 상황도 예상해야 한다. 테스트용 계정을 따로 만들고 알림 담당자와 연락 방법을 정해두면 이런 혼선을 줄일 수 있다.
가능하면 먼저 별도 시험 환경에서 기능과 점검 절차를 확인한다. 다만 시험 환경은 운영 환경과 설정이 다를 수 있다. 운영 서버에만 남은 오래된 관리자 경로나 방화벽 예외까지 그대로 재현됐다고 가정하면 안 된다. 운영 환경에서는 시험 환경에서 확인하기 어려운 설정 차이를 낮은 강도로 확인하는 편이 안전하다.
백업이 있는지보다 복구되는지 확인한다
모의해킹 일정을 잡기 전에 가장 먼저 확인하는 건 최근 백업의 복구 가능 여부다. 백업 파일의 생성 시각만 보면 부족하다. 데이터베이스와 업로드 파일을 함께 복원했을 때 화면이 열리고 주문이나 문의 내역이 맞는지 확인해야 한다. 백업이 운영 서버의 같은 디스크에만 있으면 디스크 장애나 계정 탈취 때 같이 잃을 수 있다. 별도 저장소에 보관하고 접근 권한도 운영 계정과 분리하는 게 낫다.
복구 시간도 숫자로 남겨야 한다. 예를 들어 새 서버에서 파일과 데이터베이스를 되살리는 데 40분이 걸리고 설정 확인에 30분이 더 걸린다면, 복구 목표를 30분으로 잡아둘 수는 없다. 점검 중 장애가 나더라도 무엇을 되돌릴지, 누가 되돌릴지, 실제로 얼마나 걸릴지를 알고 있어야 대응이 된다. VPS나 클라우드 서버의 스냅샷은 빠른 되돌리기에 유용하지만, 그것 하나를 장기 백업으로 취급하지는 않는다.
서버와 애플리케이션을 함께 본다
점검 순서는 자산 확인, 계정과 권한 확인, 외부에 열린 서비스 확인, 애플리케이션 기능 확인으로 잡는다. 웹서버 버전이나 열린 포트만 훑으면 로그인 후 화면에서 생기는 권한 문제를 놓친다. 일반 회원이 다른 회원의 자료를 볼 수 있는지, 관리자 기능이 서버에서도 권한을 확인하는지, 파일 업로드가 예상한 형식과 위치로 제한되는지처럼 실제 이용 흐름을 따라가야 한다.
서버 쪽에서는 관리용 접속 경로, 패치 상태, 불필요한 서비스, 인증서 만료 알림, 로그 보관 상태를 확인한다. 관리 화면에 접근 제한을 걸어도 계정 비밀번호를 여러 사람이 공유하면 추적이 어렵다. 반대로 계정 관리가 잘돼도 데이터베이스가 외부에 그대로 열려 있으면 사고 범위가 커진다. 한 항목만 통과했다고 전체가 안전하다고 볼 수 없는 이유다.
검사 중에는 서비스 상태를 같이 본다. CPU 사용률만으로 판단하지 말고 응답 시간, 오류 응답 수, 데이터베이스 연결 수, 디스크 여유 공간을 확인한다. 평소 초당 5건을 처리하던 사이트에 수십 개의 동시 요청을 보내면 보안 문제가 없어도 느려질 수 있다. 특히 저가형 웹호스팅은 계정별 자원 제한이 있으니 검사 강도를 서버 사양표만 보고 결정하면 안 된다.
발견한 문제는 재현과 재점검까지 남긴다
보고서에는 취약점 이름만 적지 않는다. 어느 기능에서 어떤 권한으로 확인했는지, 실제 영향은 어디까지인지, 수정 담당자가 무엇을 바꿔야 하는지를 남긴다. 고객 정보가 보일 가능성을 확인했다면 실제 고객 자료를 대량으로 읽거나 내려받을 필요는 없다. 영향 확인에 필요한 최소한의 증거로 멈추고, 테스트 과정에서 만든 계정과 파일도 제거한다.
수정 우선순위는 점수 하나보다 노출 범위와 피해 규모로 정한다. 외부에서 누구나 접근할 수 있는 관리자 기능과 내부 사용자에게만 보이는 낮은 영향의 오류를 같은 순서로 처리할 이유는 없다. 수정 뒤에는 문제가 사라졌는지 다시 확인하고, 수정 때문에 로그인이나 결제가 깨지지 않았는지도 확인한다. 한 번의 점검 보고서보다 이 재점검 기록이 다음 운영자에게 더 쓸모 있을 때가 많다.
작은 사이트라면 비싼 장비를 사기 전에 계정 권한, 패치, 백업 복구, 로그부터 점검해도 할 일이 꽤 많다. 모의해킹은 그 상태를 실제 이용 흐름에서 검증하는 과정으로 두는 게 좋다. 운영을 오래 해보니 큰 사고를 막은 건 화려한 검사 결과보다, 발견한 문제를 고치고 다시 확인하는 꾸준한 절차였다.
