피싱은 사용자 탓이 아니다(DNS 탓도 아니다)

기업 로그인이 여러 외부 도메인을 거치고 회사 도메인 밖에서 사용자명·비밀번호·2FA를 요구하면, 정상 인증과 피싱을 구별하기 어려워짐 토큰 만료로 불쑥 나타나는 인증 창은 URL을 무시하는 습관을 들이게 하며, 공격자는 회사 로고와 비밀번호 입력창을 갖춘 사이트만 만들면 됨 URL은 구성 요소마다 읽는 방향이 달라 2차 도메인 식별 교육이 필요하지만, 정상 서비스의 호스트명부터 신뢰할 수 없다면 교육도 소용없음 조직은 알아보기 쉬운 단일 루트 도메인 아래에 내부 서비스를 배치하고, 이메일·SMS 링크와 연락처 안내에도 같은 원칙을 적용해야 함 사용자나 DNS의 계층 구조를 탓하기보다, 정상 사이트를 사기 사이트와 구별하기 어렵게 만드는 관행을 바꿔야 함 정상 로그인 흐름이 피싱과 닮아 있음 실제 로그인 흐름에서 이름만 바꾼 예시는 회사 사이트에서 출발해 여러 외부 인증 도메인을 거친 뒤 돌아오는 구조임 회사의 www·login 하위 도메인에서 login.smallcrow.com, experience.crow-cloud.com, flock.auth.bird-security.com으로 이동함 이후 api-deadbeef.bird-security.com의 OAuth 인증과 api2.bird-security.com의 2FA 등을 거쳐 회사 사이트로 돌아옴 사용자명·비밀번호·2FA 입력 화면 모두 회사 자체 도메인 밖에 있음 토큰 만료로 예고 없이 인증 팝업까지 나타나면 정상 절차가 사기와 똑같아 보여 피싱을 알아채기 거의 불가능해짐 사용자는 URL을 무시하도록 길들여지고, 공격자는 회사 로고와 비밀번호 입력창만 갖춘 웹사이트를 만들면 됨 URL의 읽는 방향도 직관적이지 않음 호스트명과 스킴은 구체적인 것에서 일반적인 것으로 읽히지만, 경로는 반대 방향임 예시를 의미상 순서로 읽으면 최상위 도메인 → 운영자 → 서버 이름 → 프로토콜 → 디렉터리 → 파일명 순이 됨 중요한 2차 도메인이 URL 중간에 있으므로 비기술 사용자에게 식별법을 가르쳐야 하며, “수상한 링크를 피하라”는 말만으로는 부족함 다만 정상 서비스의 호스트명이 신뢰할 만한 지표가 아니라면, URL 식별 교육 자체가 무의미해짐 조직이 지켜야 할 도메인·연락처 원칙 조직은 잘 알려진 단일 루트 도메인을 반드시 사용하고, 내부 서비스는 반드시 그 하위 도메인에 두어야 함 [회사명]-auth.com, [회사명].someone-else.com, someone-e...