보안 테스트 접근 인계: 범위, 계정, 권한 회수
VPN 자격 증명을 요청하는 테스터에게 필요한 것은 범위가 정해진 인계이지 예비 로그인이 아니다. 승인을 게이트로 통과시키고, 대상을 명시하고, 계정을 발급한 뒤 회수하라.
한 테스터가 게이트웨이 주소, 내부 DNS 세부 정보, VPN 자격 증명을 요청했고, 그 요청이 «접근 필요»라는 제목으로 당신에게 전달된다. 요청만으로는 이것이 내부 평가인지, 인증이 필요한 애플리케이션 테스트인지, 아니면 누군가 범위를 잘못 이해한 공개 웹사이트 작업인지 알 수 없다. 인계를 단계마다 게이트를 두는 절차로 실행하고, 열리지 않는 첫 게이트에서 멈춰라. 그러면 모호한 요청이 승인하고, 넘겨주고, 나중에 회수할 수 있는 것이 된다.
자격 증명이 아니라 승인부터 시작하라
어떤 주소든 받은편지함을 떠나기 전에 대상의 소유자가 누구이며 누가 그 대상에 대한 테스트를 승인할 수 있는지 확정하라. 테스터는 조직이 이미 쓰는 계약 담당자를 통해 확인하고, 메일을 전달한 사람을 통해 확인하지 마라. 고객 관계는 계정에서 닿을 수 있는 모든 시스템을 테스트할 권한이 아니며, 구매 주문서는 범위 문서가 아니다.
승인된 목표를 한 문장으로 적어 인계 옆에 두라. «고객 포털의 인증을 평가한다»와 «내부 네트워크를 평가한다»는 전혀 다른 패키지로 이어지며, 그 차이는 발견 사항이 도착한 뒤가 아니라 프로비저닝 전에 정리해야 한다. 이 문장은 작업 중간에 요청이 커질 때 가리킬 대상도 준다.
경로에 호스팅 제공자나 다른 외부 업체가 있으면 그들의 요구 사항이 당신의 편의보다 앞선다. 허락 없이 남의 인프라를 테스트하는 것은 그 위에서 도는 애플리케이션을 테스트하는 것과 별개의 문제다.
관점과 대상을 명시하라
관점은 평가가 답하려는 질문이며, 테스터가 쓰려는 어떤 도구보다 접근 패키지를 더 크게 좌우한다. 공개 비인증 테스트에는 URL과 시간 창이 필요하다. 인증 테스트에는 범위 안의 특정 역할을 위한 전용 계정이 필요하고, 내부 평가에는 명시적 대상 범위가 있는 정의된 진입점이 필요하다.
| Viewpoint | What you hand over | What it does not authorize |
|---|---|---|
| Public website | Approved URL, TLS hostname, testing window | Internal network entry, adjacent hosts |
| Authenticated app | URL plus per-role test accounts | Other tenants, admin consoles outside scope |
| Private staging | Named private path and test accounts | Production systems behind the same gateway |
| Internal network | Entry point and written target ranges | Anything outside those ranges, including the gateway itself |
터널이 어디로 들어오는지는 그 뒤에 어떤 애플리케이션이 있는지와 같은 사실이 아니며, 진입점을 조사할 권한을 결코 주지 않는다. 인계에서 이를 분명히 밝혀라. «그 서브넷에 접근 권한을 줬잖아»라는 말은 발견 사항이 문제 될 때 곧바로 나온다. 서면 대상 목록만이 나중에 그것을 정리한다.
URL과 함께 TLS 호스트 이름을 주라. 맨 IP 주소는 테스터에게 이름을 추측하게 만들고, 추측한 이름은 인계 실수가 아니라 발견 사항으로 보고되는 인증서 오류를 낳는다.
만료가 있는 전용 신원을 발급하라
이 작업에만 존재하는 계정을 준비하라. 직원의 일상 로그인을 빌려주지 마라. 네트워크 도달성과 애플리케이션 권한을 합의된 작업에 맞추고, 인증 등록은 지원되는 경로로 마련하고, 회수 책임자를 이름으로 지정한 만료일을 붙여라. 자격 증명은 합의된 안전한 채널로, 사방으로 전달되는 범위 문서와 분리해 전달하라.
sudo useradd -m -e 2026-12-31 tester01 sudo passwd -S tester01 id tester01 lastlog -u tester01
누가 무엇을 언제 받았는지 기록하라. 그 기록이 통제된 인계와 아무도 추적할 수 없는 공유 비밀번호의 차이며, 사고 후 누구나 가장 먼저 요구하는 것이다. 채팅 스레드가 아니라 범위 문서와 함께 보관하고, 수령자 옆에 전달 채널을 적어라. 시각이 찍힌 한 줄은 언제나 기억을 이긴다.
만료 필드는 마지막 안전망이지 계획이 아니다. 마지막에 누군가는 네트워크 경로와 애플리케이션 역할을 제거해야 한다. 여전히 닿는 네트워크의 만료된 로그인은 회수된 접근이 아니다.
창이 열리기 전에 인계가 작동함을 증명하라
테스터의 첫 홉을 직접 실행하라. 가능한 한 테스터의 위치에 가까운 곳에서. 이름을 해석하고, 인증서 신원을 확인하고, 경로가 이웃 주소가 아니라 의도한 주소에 닿는지 확인하라.
dig +short app.example.com openssl s_client -connect app.example.com:443 -servername app.example.com </dev/null> 2>/dev/null | openssl x509 -noout -subject -dates ip route get 10.60.0.25
경로가 대상에 닿지 못하면 테스터가 대체 경로를 찾게 두지 말고 멈춰서 인계를 조정하라. 즉흥적 도달성이야말로 평가가 조용히 범위를 넘어 커지는 방식이며, 나중에 문서화되는 일은 거의 없다.
자격 증명과 함께 운영 담당자, 허용 시간, 제외 행위, 중지 조건을 보내라. 02:00에 아무도 연락할 수 없는 테스터는 당신이 승인하지 않은 판단을 내릴 것이고, 그 판단은 범위 안에 있었던 것처럼 보고서에 적힐 것이다.
NIST SP 800-115 는 기술 평가를 계획된 테스트와 그에 뒤따르는 분석 및 완화로 규정하며, 이 인계는 그 형태를 따른다. 위의 게이트는 지원 엔지니어를 위한 편집상의 설계 선택이며, 그 간행물에서 인용한 체크리스트가 아니다.
접근을 제거해 작업을 닫아라
프로비저닝의 역순으로 회수하라. 애플리케이션 역할, 그다음 네트워크 접근, 마지막으로 신원 자체. 버튼이 약속한 대로 콘솔이 했다고 가정하지 말고 각 단계를 확인하라. 세션을 죽이기 전에 계정을 잠가라. 그렇지 않으면 세션이 옛 경로로 다시 인증될 뿐이다. 그다음 닫혔다고 선언하기 전에 수립된 연결을 한 번 더 확인하라.
sudo passwd -l tester01 sudo pkill -u tester01 ss -tn state established '( sport = :443 )'
보관된 테스트 데이터를 정리하고, 처음에 합의한 보고 절차로 개선을 추적하라. 보고서에는 환경, 접근 수준, 범위, 한계를 밝혀야 한다. 한 번의 평가에서 나온 발견 사항을 기록하는 것이지 사이트가 안전하다는 영구적 선언이 아니다.
회수 기록을 인계 기록과 함께 보관하라. 다음 작업이 열릴 때 지난번에 무엇이 제거되었고 누가 승인했는지 정확히 알고 싶을 것이며, 기억으로 그림을 다시 그리려 하지는 않을 것이다.