과기정통부·KISA 긴급 대응체계 가동…2.8만 기업에 보안점검 권고
AI를 활용하여 생성한 이미지입니다.
금융권에서 개인정보 유출과 비정상 접근이 잇따르자 과학기술정보통신부와 한국인터넷진흥원(KISA)이 민간 분야 확산을 막기 위한 긴급 대응체계를 가동했어요. 10월 4일에는 약 2만8000개 CISO 신고기업에 보안점검 권고 메일도 발송했어요.[1][2]
이번 조치는 금융회사만의 점검으로 끝내지 않겠다는 뜻에 가까워요. 금융권 공격에 사용된 방식이나 인프라가 다른 기업의 외부 서비스로 번질 가능성을 염두에 두고, 민간 기업의 노출된 웹 서비스와 계정·접근통제를 함께 확인하는 흐름이에요.
무슨 대응이 시작됐을까?
KISA 인터넷침해대응센터(KISC)는 추가 피해에 빠르게 대응할 수 있도록 대응체계를 강화했어요. 주요 기업 홈페이지 모니터링을 늘리고 침해사고 대응 인력을 보강했으며, 비상출동조도 상시 대기하도록 했다고 밝혔어요.[1]
기업이 참고할 수 있는 위협 정보도 보호나라와 사이버위협정보 분석·공유 체계(C-TAS)를 통해 제공하고 있어요. C-TAS는 악성코드, 공격자 인터넷 주소(IP), 최신 사이버위협 동향 등을 공유하는 플랫폼이에요. 보안팀은 공지 내용을 읽는 데서 멈추지 말고, 우리 회사의 외부 노출 자산과 대조해야 해요.
금융보안원이 확인한 해외 공격자 IP에 대해서는 해당 클라우드 사업자에게 위협 정보를 전달하고 악성행위 차단을 요청하는 조치도 진행됐어요.[1] 공격 IP 하나를 막는 것만으로 모든 문제가 끝나는 것은 아니지만, 이미 알려진 인프라가 계속 접근하는 상황을 줄이는 데는 의미가 있어요.
2.8만 기업에 보낸 메일이 중요한 이유
이번에 점검 권고를 받은 대상은 약 2만8000개의 CISO 신고기업이에요.[1][2] CISO는 조직의 정보보호 업무를 책임지는 임원을 뜻해요. 대상 기업은 규모가 큰 곳만을 의미하지 않지만, 모든 국내 기업이 자동으로 점검을 받는다는 뜻도 아니에요.
메일을 받지 않았다고 해서 점검 대상이 아니라는 의미는 아니에요. 외부에서 접속하는 로그인 화면, 문의·조회 API, 관리자 페이지, 오래된 VPN과 원격관리 도구가 있다면 같은 방식으로 확인해야 해요. 특히 내부 시스템과 연결된 외부 웹페이지는 기능이 작아 보여도 권한이 넓을 수 있어요.
기업이 먼저 확인할 네 가지
- 외부 노출 자산을 다시 세어 보세요. 도메인과 IP 목록에 테스트 서버, 오래된 서브도메인, 협력사 운영 페이지가 빠져 있지 않은지 확인해요.
- 인증 없는 조회 경로를 점검하세요. 번호나 날짜를 바꿔가며 반복 요청할 수 있는 API가 있는지, 서버가 요청 횟수와 비정상 패턴을 기록하는지 봐야 해요.
- 접근권한을 실제 업무와 맞추세요. 직원용 화면이나 협력사 계정이 고객·직원 정보까지 조회할 수 있다면 권한을 줄이고 추가 인증을 적용하는 편이 안전해요.
- 로그를 보관하고 연락망을 확인하세요. 이상 징후를 발견했을 때 누가 판단하고, 어떤 기관과 클라우드 사업자에 연락할지 미리 정해 둬야 해요.
아직 모르는 부분도 있어요
현재 보도된 내용만으로는 이번 금융권 공격의 전체 경로와 모든 피해 규모가 확정된 것은 아니에요. 과기정통부와 KISA의 대응은 유사 공격의 민간 확산을 막기 위한 조치이고, 개별 금융사 사고의 원인과 책임은 금융당국과 수사·조사 절차에서 따로 확인될 수 있어요.
따라서 기업이 해야 할 일은 특정 공격 도구 이름을 찾아내는 데만 집중하는 것이 아니에요. 외부 서비스가 무엇을 공개하고 있는지, 인증과 권한 검사가 실제 요청마다 작동하는지, 자동화된 반복 요청을 어떻게 발견할지부터 확인해야 해요. 권고 메일의 링크를 열기 전에 회사 보안 담당자와 발신 주소를 확인하고, 의심스러운 파일이나 로그인 페이지에는 사내 절차로 신고하세요.
이번 이슈를 이렇게 읽으면 돼요
이번 긴급 대응은 보안 사고가 난 뒤 복구하는 단계를 넘어, 민간 기업 전체가 외부 노출 자산을 다시 세어 보라는 신호예요. 다만 권고 메일을 받았다는 사실만으로 침해를 당했다는 뜻은 아니고, 메일을 받지 않았다고 안전하다는 뜻도 아니에요. 기업별로 외부 자산과 접근권한을 확인하고, 문제가 발견되면 로그를 보존한 뒤 공식 신고·지원 경로로 넘기는 것이 현실적인 다음 행동이에요.
보안팀이 놓치기 쉬운 연결고리
외부 자산을 점검할 때 도메인 목록만 확인하면 부족해요. DNS에 남은 옛 주소, 클라우드 로드밸런서 뒤의 원본 서버, 개발팀이 임시로 만든 테스트 API까지 실제 인터넷에서 접근되는지 확인해야 해요. 자산 목록과 취약점 스캐너 결과가 다르면 어느 쪽이 맞는지 판단하기 전에 소유 부서와 운영 상태부터 확인하는 편이 안전해요.
권한도 화면 단위가 아니라 데이터 흐름으로 봐야 해요. 로그인한 일반 직원이 어떤 API를 호출할 수 있고, 협력사 계정이 어떤 필드를 반환받는지, 실패한 요청이 로그에 남는지를 함께 확인해야 해요. 공격자는 정상적인 로그인 절차를 통과한 뒤 권한이 넓은 기능을 악용할 수도 있기 때문이에요.
사고가 의심될 때의 순서
이상한 요청을 발견하면 곧바로 로그를 지우거나 서버를 재설치하지 않는 것이 좋아요. 먼저 시간대와 요청 경로, 계정, 응답 코드, 관련 IP를 별도 보관하고, 영향을 받을 수 있는 시스템의 인증정보를 교체할 범위를 정해요. 그다음 외부 노출을 줄이되 조사에 필요한 원본 로그는 보존해야 해요. 외부 클라우드나 보안업체에 차단을 요청할 때도 차단 시각과 대상 주소를 기록해 두면 사후 분석이 쉬워져요.
과기정통부와 KISA의 권고는 모든 기업이 침해됐다는 통지가 아니에요. 점검을 시작하라는 신호에 가까워요. 회사 안에 전담 보안팀이 없다면 인터넷 자산 목록, 관리자 계정, 개인정보를 반환하는 API 세 가지부터 외부 전문업체와 함께 확인하는 것이 현실적인 출발점이에요.
