대상: 일본에서 개인정보를 다루는 기업 또는 조직에서 시스템을 운영하는 담당자와 이들이 보고하는 경영진. 2026년 10월, 일본 정부 기관과 국가 보안 기관은 무단 접근에 관한 일련의 경고를 발표했습니다. 이 가이드는 이를 이번 주에 자체 시스템에서 실행할 점검 사항으로 정리합니다. 내각관방 국가사이버보안실, IPA(정보처리추진기구), JPCERT/CC, 개인정보보호위원회(PPC), 금융청(FSA), 경찰청(NPA)의 공개 문서를 바탕으로 하며, 모두 일본어 문서입니다. 공격 기법은 다루지 않습니다.
이 경고가 지금 나온 이유
2026년 9월경부터 일본의 조직들은 무단 접근으로 인한 정보 유출 사고를 잇달아 공개해 왔습니다. IPA에 따르면 공개는 금융기관과 통신사를 포함한 다양한 기업에서 나왔으며, 온라인 및 계정 서비스를 제공하고 대량의 개인정보를 다루는 시스템이 침입당해 개인정보를 포함한 데이터가 탈취되었습니다.
다음 문서들은 10월 7일부터 9일 사이에 발표되었습니다.
| 날짜 | 발행 기관 | 문서 | 주요 내용 |
|---|---|---|---|
| 10월 7일 (해설 동영상 10월 9일 추가) | 개인정보보호위원회 | 대규모 정보 유출 대응(경고), 개정된 "WARNING: 무단 접근으로 인한 개인정보 유출 방지" | 기술적 안전조치 개정 예시 사전 공개(2027년 4월 확정 예정), 더 이상 필요 없는 개인정보 삭제, API 악용 등 9개 사례 유형 |
| 10월 8일 (10월 9일 및 23일 갱신) | JPCERT/CC | 일본 조직에서 발생한 최근 일련의 무단 접근 사고에 대한 경고(JPCERT-AT-2026-0030) | 확인된 공격 패턴 5개, 대응책, 조사용 지표(IOC) |
| 10월 9일 | 내각관방 국가사이버보안실 | 무단 접근에 의한 데이터 유출에 대한 대응 | 세 가지 축: 웹 시스템, 공급망, 데이터 관리 |
| 10월 9일 | IPA | 무단 접근에 의한 데이터 유출을 고려한 신속한 조치 | 지금 실행할 점검 사항과 조치(필요에 따라 갱신) |
| 10월 9일 | 금융청 | 현재 상황에서의 사이버보안 강화 및 계좌 개설 처리 | 금융기관에 통제 점검과 본인확인 강화 요청 |
JPCERT/CC는 여러 제품과 서비스가 영향을 받았지만 기술 정보 공유가 부족하고 알려진 내용이 제한적이라고 밝혔습니다. 어떤 문서도 개별 사고를 명시하지 않습니다. 이 사이트가 9월과 10월에 다룬 일본의 무단 접근 사고로는 Times Car, Yamato Transport 및 Sagawa Express, Seicomart 앱, Yakiniku King 앱, Daiwa Securities 협력업체, Lawson ID가 있습니다. 각 기업이 공개한 내용은 링크된 기사에 있습니다.
이번 주 점검: IPA의 세 영역
IPA는 "신속히 실행할 점검 사항" 아래 세 영역을 제시합니다. 아래에서는 이를 구체적인 과제로 나누었습니다. 모든 항목은 직접 관리하는 시스템에서만 실행하십시오.
인터넷에 노출된 앱을 목록화하고 로그를 검토하되, 지난 1개월을 먼저, 그다음 3개월을 봅니다
인터넷에서 접근 가능한 자사 구축 또는 운영 앱과 서비스를 모두 나열하십시오. 회원 사이트, 모바일 앱이 호출하는 API, 문의 양식, 관리자 화면 등이 포함됩니다. JPCERT/CC는 BI 도구와 직원용 관리 시스템처럼 일반 공개를 목적으로 하지 않은 시스템도 피해를 입었다고 밝혔으므로, 내부용 시스템도 포함하십시오.
각 앱의 로그에서 비정상적인 것을 확인하십시오. IPA의 예시는 대량의 오류와 평소와 다른 패턴입니다. 실제로는 웹 서버 접근 로그에서 관리자 화면이나 API 요청의 급증, 애플리케이션 로그에서 반복되는 동일 오류, 야간이나 주말의 대량 조회를 살펴보십시오. 지난 1개월부터 시작해 3개월로 범위를 넓히십시오.
IPA는 여러 번 조사해야 할 수도 있으므로 누가 어떻게 조사할 수 있는지도 미리 알아 두라고 요청합니다. 마지막으로 각 앱과 서비스의 구성 요소(예: OS, 미들웨어, 라이브러리, CMS)에 적용되지 않은 보안 패치가 있는지 확인하고, 가능한 한 빨리 적용하십시오.
API의 경우 PPC가 10월 7일 개정한 WARNING 문서는 사례 9 "API 악용"을 추가했습니다(2024년 12월 11일 초판에는 사례 1부터 8까지 있었습니다). 문서가 든 원인은 다음과 같습니다. 일부 API가 관리 대상에서 누락되어 있었고, 회원 ID 같은 매개변수를 바꾸면 로그인한 사용자가 다른 사용자의 데이터를 조회할 수 있었으며, 응답에 불필요한 정보가 포함되었고 회원 ID가 순차적이었으며, 요청량 제한(레이트 리미팅)이 없었습니다. 문서가 제시한 대응 예시는 다음과 같습니다.
- API를 정기적으로 목록화하십시오
- 인증(사용자가 누구인지)뿐 아니라 모든 요청에 대해 권한(이 사용자가 이 데이터에 접근할 권한이 있는지)을 확인하십시오
- 응답에서 불필요한 정보를 제외하고, 회원 ID와 레코드 번호에는 UUID 같은 임의 값을 사용하십시오
- 짧은 시간에 대량 요청을 탐지해 차단하는 레이트 리미팅을 구현하십시오
클라우드, VPN 및 기타 외부 서비스에서 로그인 실패, 접속 주소, 미확인 계정을 확인합니다
사용 중인 클라우드 서비스, VPN, SaaS를 나열하십시오. IPA는 개별 부서가 가입한 서비스도 포함하라고 요청합니다. 재무 및 영업 부서에 IT팀이 모르는 계약이 있는지 물어보십시오.
각 서비스의 로그에서 다수의 로그인 실패, 낯선 출발지 IP 주소, 비정상적인 시간대의 로그인을 확인하십시오. IPA는 서비스마다 보관 기간이 다르고, 제공자와 고객이 서로 다른 로그를 볼 수 있다고 설명합니다. 관리 콘솔에 짧은 기간만 표시된다면 제공자에게 문의하십시오.
계정의 경우 알아볼 수 없는 계정이 새로 만들어졌는지, 비활성화하거나 삭제했던 계정이 다시 활성화되었는지 확인하십시오. IPA는 계정 작업의 감사 로그를 검토하면 도움이 된다고 밝힙니다. 이는 조직 차원에서 내 계정에 누가 접근했는지 확인하는 것과 같습니다.
같은 WARNING의 사례 8은 기업이 사용한 클라우드 서비스에서 발생한 유출입니다. 클라우드 제공자의 업무 시스템에 무단 접근이 있었고, 다수의 고객 회사에 속한 개인정보가 암호화되었습니다. PPC가 든 원인 중 하나는 고객들이 위탁 계약이 아닌 클라우드 서비스 이용을 개인정보 위탁으로 보지 않아서, 그 처리 방식을 감독하지 않았다는 점입니다. 대응책으로 PPC는 서비스를 선택하기 전에 이용약관과 서비스의 보안 평가 문서를 통해 클라우드 서비스가 적절한 보안 조치를 갖추고 있는지 확인하라고 제시합니다.
보유한 개인정보를 목록화하고 필요 없는 정보는 삭제합니다
IPA는 탈취된 데이터가 협박과 재판매에 쓰이고 있다고 밝히며, 조직에 필요한 데이터만 보유하고 무엇을 보유하는지 정확히 알 것을 요청합니다. 각 데이터베이스와 파일 저장소에 대해 어떤 데이터가 있는지, 레코드가 몇 건인지, 왜 보유하는지, 언제까지 보유하는지 적어 두십시오. 설명할 수 없는 정보는 삭제 대상입니다.
같은 주에 나온 PPC의 경고는 일본 개인정보보호법 제22조가 개인정보가 더 이상 필요하지 않게 되면 지체 없이 삭제하도록 노력할 것을 요구한다고 상기시키며, 이를 하지 않아 상황이 악화된 사례를 보았다고 밝혔습니다. 법령이 보관 기간을 정하고 있다면 그 근거와 기간도 함께 기록하십시오.
IPA는 또한 공공기관과 보안 업체가 의심스러운 IP 주소 등 조사에 유용한 정보를 공개할 수 있다고 밝히며, 당분간 정보 수집을 강화할 것을 요청합니다.
점검 결과가 깨끗하더라도 계속하십시오
IPA는 이상이 발견되지 않더라도 추가 조치를 검토하라고 요청합니다. 인터넷에 노출된 앱과 외부 서비스의 경우 노출된 항목을 검토하고, 다중 인증 및 비밀번호 같은 인증을 강화하며, 계정 권한을 검토하고, API 연동 관리 방식을 검토하고, 무엇을 얼마나 오래 기록하는지 검토하십시오. 데이터의 경우 보관 여부를 다시 검토하고, 저장 위치를 다시 검토하고, 접근 기록과 그 보관 기간을 검토하고, 암호화하십시오.
국가사이버보안실의 세 가지 축을 구체적인 점검으로
국가사이버보안실의 공지는 웹 시스템 취약점 악용, 공급망을 통한 침해, 취약한 데이터 관리를 배경으로 제시하고, 각 영역의 핵심 조치를 제시합니다. 오른쪽 열은 공지 항목을 자사에서 확인할 수 있는 질문으로 바꾼 것입니다.
| 축 | 공지의 주요 항목 | 점검 사항 |
|---|---|---|
| 1. 웹 시스템의 적절한 관리 | 보안 패치 신속 적용(인터넷에 노출되지 않은 내부 서버 포함), 지원이 끝난 제품 사용 중단, 미사용 시스템과 기능 종료, 정기적인 취약점 진단, 불필요한 포트와 서비스 비활성화 | 공개 서버와 내부 서버 각각의 지원 종료일과 마지막 업데이트를 목록으로 만들 수 있습니까? |
| 1. (계정 및 인증) | 다중 인증, 추측하기 쉬운 비밀번호 금지, 관리자 계정 최소화, 퇴사자·부서 이동자·미사용 계정 신속 비활성화 | 모든 관리자 계정의 소유자를 말할 수 있습니까? 퇴사자 계정이 아직 활성 상태입니까? |
| 1. (복원력) | 로그 수집 및 보관, 의심스러운 트래픽과 대량 접근 모니터링, 외부에서 오는 비정상 인증 시도 탐지, 사고 대응 준비 | 대량 조회나 반복적인 로그인 실패가 발생하면 누구에게 알림이 갑니까? |
| 2. 협력업체를 포함한 공급망 | 협력업체의 정책, 구조, 책임 분담 확인, 재위탁 업체의 상태도 파악, 접근 통제·로깅·침해 보고 의무를 계약에 명시, 협력업체에 필요한 데이터만 제공, 업무 종료 후 삭제 보장 | 각 협력업체에 대해 공유한 개인정보, 부여한 계정, 사고 연락처를 한 장으로 정리할 수 있습니까? |
| 3. 적절한 데이터 관리 | 정보의 위치와 관리 주체 파악, 목적과 보관 기간 정의, 정기적 목록화, 읽기와 쓰기 권한 분리, 저장 데이터와 전송 데이터 암호화, 자격 증명을 평문으로 저장하지 않음, 클라우드 노출과 접근 설정 점검, 개인정보 접근 기록 및 대량 조회 감시 | 나중에 누가 언제 개인정보에 접근했는지 찾아낼 수 있습니까? |
공급망에 대해 공지는 조직이 "협력업체와 함께 관리한다"는 인식을 바탕으로 행동할 것을 요청합니다. 공격자가 방어가 약한 협력업체를 발판으로 삼아 대상 기업으로 접근을 확대하는 경우가 있기 때문입니다. 협력업체와 유지보수 계정은 조직을 위한 보안 기준선에서도 다룹니다.
국가사이버보안실: 무엇을 보호할지
웹 시스템 / 협력업체를 포함한 공급망 / 데이터 관리
IPA: 이번 주 무엇을 점검할지
인터넷 노출 앱 로그 / 외부 서비스 계정 / 보유 데이터
JPCERT/CC: 무슨 일이 일어나고 있는지
공격 패턴 5개 / 대응책 / 조사 단서(IOC, 갱신됨)
PPC의 개정 기술적 안전조치 사전 안내
10월 7일 경고의 별첨에서 PPC는 일본 개인정보보호법에 따른 일반 가이드라인 별첨의 "10-6 기술적 안전조치" 개정 내용을 제시했습니다. PPC는 개정이 내년 4월(2027년 4월)에 확정될 예정이지만, 최근 상황을 고려할 때 참고 자료로 더 유용할 가능성이 크기 때문에 계획된 내용을 미리 보여준다고 밝힙니다.
별첨에 든 것은 "방법의 예시"입니다. PPC는 이것이 문자 그대로 예시이며, 위반을 피하기 위해 모든 항목이 반드시 갖춰져야 하는 것은 아니라고 설명합니다. 또한 구체적인 방법은 개인정보 유출 시 개인에게 미칠 피해와 취급하는 개인정보의 성격 및 양 등 위험에 맞아야 한다고 밝힙니다. 대량의 개인정보를 보유한 기업은 이 내용과 자사 통제를 항목별로 비교해야 합니다. 별첨은 중소기업을 위한 별도 예시도 제공합니다.
| 영역 | 별첨의 예시(요약) | 점검 사항 |
|---|---|---|
| (1) 접근 통제 | 개인정보를 취급하는 시스템에 대한 접근을 최소화합니다(예: 사전에 승인된 특정 IP 주소에서만 허용). 특권 계정을 누가, 어떤 기기로, 언제 사용하는지 최소한으로 유지합니다. 정기 감사 등으로 접근 권한을 검토합니다. 접근 요청마다 출발지 위치, 시간, 기기 보안 상태 등 상황을 평가하고 위험에 근거해 결정합니다 | 관리자 화면이나 데이터베이스에 어디서든 접근할 수 있습니까? 특권 계정과 그 계정을 쓰는 기기를 목록으로 만들 수 있습니까? |
| (2) 식별 및 인증 | 조직 네트워크 외부에서의 접근, 관리자 권한 접근, 중요한 개인정보 접근에 대해 다중 인증(피싱 방지 방식 포함)을 사용합니다. 직원이 아닌 이용자도 적절히 식별하고 인증합니다(예: 마찬가지로 다중 인증) | 모든 원격 접속과 관리자 로그인에 예외 없이 다중 인증이 요구됩니까? 회원 및 기타 이용자에게도 제공됩니까? |
| (3) 외부로부터의 무단 접근 방지 | 방화벽, 보안 소프트웨어, 패치 적용, 승인되지 않은 소프트웨어 방지. 조직이 승인하고 보안 기준을 충족하는 기기에서만 개인정보 접근을 허용합니다 | 개인정보를 다루는 기기가 회사가 승인한 기기뿐입니까? |
| (4) 시스템 사용을 통한 유출 방지 | 기능 점검용 테스트 데이터로 쓰이는 개인정보는 최소화합니다(예: 금지하거나 일부를 다른 데이터로 대체). 클라우드에서 개인정보를 삭제할 때는 제공자의 방법이나 암호화 소거(crypto-erase) 등 복구를 어렵게 하는 방법을 사용합니다 | 실서비스 개인정보의 사본이 테스트 환경에 남아 있습니까? 클라우드 서비스를 해지하거나 이전할 때 데이터 삭제 방식이 정해져 있습니까? |
| (5) 무단 접근 탐지 | 인증, 접근, 운영, 네트워크 로그를 정해진 기간 보관하고, 유출, 변조, 무단 삭제로부터 보호하며, 정기적으로 분석합니다. IDS/IPS, EDR 등으로 지속적으로 모니터링합니다. 침해되었거나 침해되었을 가능성이 있는 시스템을 정지 또는 격리하고 계정을 비활성화하여 피해 확산을 제한합니다 | 공격자가 삭제할 수 없는 곳에 로그를 보관합니까? 누가 시스템 격리와 계정 비활성화를 결정할 수 있습니까? |
(5)행의 로그 보관은 IPA의 "지난 1개월, 그다음 3개월" 점검이 의존하는 기반이기도 합니다. 이번 주 점검에서 로그가 충분하지 않다는 결과가 나오면, (5)행이 이를 개선할 근거가 됩니다.
JPCERT/CC가 확인한 다섯 가지 패턴
JPCERT/CC의 경고는 랜섬웨어와는 별개로 대규모 데이터 유출로 이어지며 특히 증가하고 있는 것으로 보이는 공격 패턴을 설명합니다. 여기서는 어디를 살펴봐야 하는지 보여 줄 정도로만 요약합니다.
| 패턴 | JPCERT/CC 설명 요약 | 점검 위치 |
|---|---|---|
| 사례 A | 알려진 취약점을 탐색하고 악용을 시도하며, 관리가 허술한 장비를 악용해 설정 파일이나 백업 파일을 가져가려는 시도 포함 | 공개 서버의 패치 수준, 공개 폴더에 설정 파일이나 백업이 있는지 여부 |
| 사례 B | 앱의 관리자 API에 대한 무단 요청으로 데이터가 변경됨. 보고에는 공개 앱 분석을 통한 API 식별, 내부 API 공격, 다른 시스템에서 탈취한 API 키의 악용이 포함됨 | 관리자 및 내부 API가 인증과 접근 통제를 요구하는지 여부, API 키의 권한과 만료 |
| 사례 C | 무단 API 요청을 통해 Metabase의 SQL 인젝션 취약점(CVE-2026-72898)을 악용 | Metabase 사용 여부, 패치 여부, 인터넷에서 접근 가능한지 여부 |
| 사례 D (9일 추가) | 공개 웹 서버에서 접근 가능한 애플리케이션 서버에 WAR 파일(패키징된 Java 애플리케이션)을 배치하고, 내부 파일이 간단한 웹 셸(외부인이 명령을 실행하도록 하는 악성 프로그램) 역할을 함 | 애플리케이션 서버의 관리 기능이 공개 측에서 접근 가능한지 여부, 배포된 모든 앱이 자사가 배포한 것인지 여부 |
| 사례 E (23일 추가) | AI 기반 침투 테스트 플랫폼을 악용하는 공격 시도. 플랫폼 이름은 JPCERT/CC 경고에 나열되어 있음. 주로 인터넷에 노출된 웹 애플리케이션을 대상으로 다양한 취약점을 탐색하고 악용을 시도하며, 관리가 허술한 장비를 악용하는 공격(설정 파일이나 백업 파일 가져가기 등)도 확인됨. 인터넷에 노출된 WSUS 서버(조직 내에서 Windows 업데이트를 배포하는 서버)에 대한 시도도 포함 | 공개 웹 앱의 패치 수준과 공개 폴더 내용, WSUS 서버가 인터넷에서 접근 가능한지 여부 |
사례 C는 Metabase 취약점 침해 사고와 CVE-2026-72898 해설에서 다룹니다. 잘못된 위치에 있는 설정 파일과 백업에 대해서는 공개 디렉터리에 비밀 파일을 두었습니까?를 참고하십시오.
10월 15일 JPCERT/CC는 공격에 사용되었을 수 있는 서버를 조사한 결과를 발표했습니다. 공격자가 AI를 사용해 알려진 취약점을 스캔하고 API를 통해 공격했으며, Android 앱 배포 파일을 분석해 API를 식별하고 SSRF 같은 결함을 탐색한 흔적도 있었다고 밝혔습니다. 이는 사례 B의 "공개 앱 분석을 통한 API 식별"과 일치합니다. JPCERT/CC는 앱에 내장된 비밀 정보와 API 인증 로직은 (예: Flutter 앱처럼) 컴파일된 코드에서도 추출될 수 있다고 지적하고, 다음을 권고합니다.
- API 인증에 쓰이는 개인 키나 장기 자격 증명을 앱에 내장하지 마십시오
- 앱 내 서명이나 난독화에만 의존하지 말고, 서버에서 사용자를 인증하고 대상과 내용에 따라 각 작업을 승인하십시오
- 요청량 제한을 적용하고 비정상 요청을 모니터링하며, 공식 앱 이외의 클라이언트에서의 접근을 가정하십시오
- 외부 URL을 가져오는 API는 목적지를 제한하고, 리다이렉트 목적지도 확인하십시오
API를 통한 접근에 대해 JPCERT/CC는 로그인, 비밀번호 재설정, SMS 발송, 검색 기능별 요청량 제한, 비공개 API를 포함한 접근 통제, API 사용자와 토큰에 대한 최소 권한 및 적절한 만료 기간, 불필요하거나 유출되었을 수 있는 토큰을 신속히 폐기할 수 있는 능력을 권장합니다. 일반 대책으로는 특정 지역에서만 쓰는 서비스의 접근 출발 지역 제한, 알려진 취약점에 영향을 받는 버전 업데이트, 웹 서버가 침해되었을 때 내부 이동을 제한하는 방법 검토, 탐지와 초동 대응 점검, 불필요한 관리 기능을 인터넷에서 분리, 보관 기간이나 목적이 지난 데이터 삭제, 유출 시 고객에게 2차 피해를 경고할 준비가 포함됩니다.
일본 보안 기업의 발견 사항(10월 7일부터 19일까지)
일본 보안 기업들도 처리한 사례와 공격자 서버 조사를 바탕으로 한 결과를 발표했습니다. 한 기업은 2026년 7월 이후(10월 6일 기준) 일본 조직이 공개한 웹 시스템 유출 81건을 분석했고, 그중 65건(80.2%)은 공지에 충분한 설명이 없어 원인별로 분류할 수 없었다고 밝혔습니다. 이 기업이 처리한 사례에서 확인된 방법에는 필요 이상의 데이터를 반환하는 API, 서버의 권한 확인 누락, 익명 사용자가 접근할 수 있는 회원 전용 기능, 스마트폰 앱에서 추출된 API 키가 포함됩니다.
다른 기업은 공격자가 WAF 차단 임계값에 도달하기 직전에 다른 IP 주소로 전환했으며, 총 수백 개의 IP 주소를 사용했다고 설명합니다. 또한 CVE에 나열되지 않은 버전과 지원이 종료된 버전도 같은 취약점의 영향을 받을 수 있다고 밝힙니다. 10월 19일 이 기업은 공격자 서버에서 AI 기반 자율 침투 테스트 시스템이 사용되고 있음을 확인했다고 발표했습니다. 10월 23일 JPCERT/CC는 AI 기반 침투 테스트 플랫폼을 악용하는 공격 시도를 경고에 사례 E로 추가했습니다.
위의 점검 외에 다음 세 가지를 추가하십시오.
- 관리 화면과 기타 관리 기능이 실제로 취약점 진단 범위에 포함되었는지 확인하십시오(공개되지 않은 기능은 종종 빠집니다)
- IP별 요청 제한이나 WAF에만 의존하지 말고, WAF가 있다는 이유로 패치를 미루지 마십시오
- 자유 입력 메모 항목에 저장된 정보를 포함해 더 이상 필요 없는 개인정보를 줄이고, 종료된 서비스의 API 키를 폐기하십시오
지표(IP 주소, User-Agent)는 JPCERT/CC의 최신 페이지를 사용하십시오
JPCERT/CC의 경고에는 의심스러운 출발지 IP 주소와 공격에서 확인된 User-Agent 예시가 나열되어 있습니다. 목록은 10월 9일과 23일에 확장되었고 다시 바뀔 수 있으므로, 이 사이트는 목록을 복사하지 않습니다. 최신 목록은 JPCERT/CC 경고(JPCERT-AT-2026-0030, 일본어)에서 확인하십시오.
JPCERT/CC는 조직에 나열된 IP 주소가 자사에 접근했는지 확인해 이미 공격을 받았는지 알아보라고 요청합니다. 이 목록은 차단 목록이 아니라 과거 로그 검색의 단서로 사용하십시오. 10월 23일 사례 B에 추가된 내용은 다음과 같습니다.
- 새로운 출발지 IP 주소 하나와, 공격이 관찰되었거나 공격 인프라가 활성화된 것으로 추정되는 날짜(JST). JPCERT/CC는 해당 날짜 이외에도 공격이 시도되었을 수 있다고 밝힙니다. 사례 E에는 별도의 IP 주소 목록이 있습니다
- User-Agent 예시로, 공개 앱과 동일한 User-Agent입니다. 즉 User-Agent만으로는 공격 트래픽과 정상 앱을 구분할 수 없습니다
- TLS 지문 예시. JPCERT/CC는 나열된 JA4 값이 일반적인 Python HTTP 클라이언트와 같아서 공격자를 단독으로 식별할 수 없으며 다른 단서와 함께 봐야 한다고 씁니다
- 나열된 주소 외에도 Tor 출구 노드와 주거용 프록시(가정용 인터넷 연결을 통해 트래픽을 중계하는 서비스)를 통한 접근이 확인되었습니다
JPCERT/CC는 이것이 조사 당시에는 정당한 이용이었을 수 있다고 밝히므로, 일치한다는 사실만으로 침입이 증명되지는 않습니다. 로그에서 해당 출처가 실제로 무엇을 했는지 확인하십시오.
무언가 발견하면: 다음 순서로 진행하십시오
IPA는 비정상적인 로그나 계정을 발견하면 보안 사고를 신속히 선언할 것을 요청합니다. 상황을 지켜보며 기다리면 누군가 확인하기 전에 로그가 만료될 수 있습니다.
보안 사고를 선언합니다
이상 징후를 같은 날 담당자에게 보고하고 사고로 다루기로 결정하십시오. 선언은 나중에 철회할 수 있지만, 늦게 시작한 조사를 앞당길 수는 없습니다.
로그와 증거를 보존합니다
로그는 보관 기간이 끝나면 사라집니다. 무언가를 삭제하거나 덮어쓰기 전에 서버 로그, 외부 서비스 콘솔에서 내보낼 수 있는 로그, 계정 감사 로그를 별도 위치에 복사하십시오. 서버를 재구축하기 전에 디스크 이미지를 보존할지 전문가에게 물어보십시오. 단계별 순서는 웹사이트나 서버가 해킹되었는지 확인하는 방법의 "이상을 발견했을 때 먼저 할 일"에 있습니다.
전문 업체를 투입합니다
데이터 유출 가능성을 감안해 IPA는 상세 조사를 위해 전문 보안 업체의 도움을 강하게 권장합니다. JPCERT/CC도 사고 대응 요청을 받습니다. 공격자가 어디까지 들어왔는지, 무엇이 탈취되었는지를 혼자 판단하지 마십시오.
2026년 10월 16일 IPA는 피해를 입었거나 입었을 수 있는 기업과 조직을 위한 무단 접근 특별 상담창구를 열었습니다. 이곳에서는 피해 가능성과 초동 조치에 대해 상담하고, 사고 대응을 취급하는 업체 목록을 안내하며, 다른 상담·신고 창구를 알려 줍니다(전화 03-6759-5760, 평일 9:30–17:30, 12:00–13:00 제외, 일본어 상담. 이메일도 접수합니다). 어느 업체에 연락해야 할지 모르겠다면 여기서 시작할 수 있습니다.
PPC에 보고하고 정보를 공유합니다
개인정보가 유출되었거나 유출되었을 가능성이 있다면 PPC에 보고하고 영향받는 사람에게 통지해야 할 수 있습니다. 기한과 보고 장소는 웹사이트나 서버가 해킹되었는지 확인하는 방법에 요약되어 있습니다. 국가사이버보안실은 피해 조직이 추가 피해를 막기 위해 기술 정보를 자신과 관계 부처, 전문 기관에 신속히 공유할 것을 요청합니다. IPA의 신고 창구와 경찰 사이버수사 창구도 이용할 수 있습니다.
경영진에게 전할 내용
국가사이버보안실의 공지는 유출이 업무 중단, 고객 대응 및 기타 경영 위험으로 이어질 수 있으므로 사이버 공격의 피해는 더 이상 IT 부서만의 문제가 아니라고 밝힙니다. 경영진에게 사이버보안을 경영 문제로 다루고, 필요한 투자와 인력 배치를 포함해 강화할 것을 요청합니다. IPA도 경영 책임의 차원에서 조치를 긴급히 검토할 것을 요청합니다.
위로 보고할 때는 경영진이 결정할 수 있도록 네 가지 항목으로 정리하십시오.
- 이번 주 결과: 세 영역 각각에서 이상을 발견했는지, 발견하지 못했는지, 확인할 수 없었는지
- 확인하지 못한 것: 로그가 없는 기간, 파악하지 못한 외부 서비스나 협력업체
- 필요한 결정: 로그 보관 기간 연장 비용, 전문 업체와의 상시 계약, 협력업체에 대한 요청
- 고객 대응 준비: 유출 시 공지 문안과 연락 창구(JPCERT/CC는 2차 피해 경고를 미리 준비할 것을 권장합니다)
일부 업종은 규제 기관으로부터도 요청을 받았습니다. 금융청은 금융기관에 제3자 위험 관리와 사고 대응을 포함해 통제를 점검하고, 발견된 공백을 신속히 조치하라고 요청했습니다. 또한 온라인 본인확인에서 신분증 이미지와 얼굴 이미지에 부자연스러운 부분이 있는지 확인하고, 신분증 이미지 제출이 인정되지 않게 되는 2027년 4월 1일보다 앞서 IC칩 판독으로 조기 전환할 것을 요청했습니다.
이 사이트의 견해: '로그가 없었다'는 것은 실패한 점검이 아니라 하나의 결과입니다
IPA의 점검은 1개월, 그다음 3개월을 되돌아볼 수 있다는 전제에서 출발합니다. 실제로는 로그가 30일 후 만료되도록 설정되어 있었거나, 외부 서비스 콘솔에 2주치만 표시된다는 사실을 팀이 발견하는 경우가 많습니다.
이런 경우 "이상 없음"으로 보고하지 마십시오. 정확한 보고는 "지난 1개월 동안 이상 없음. 그 이전 기간은 확인할 수 없었음"입니다. 어떤 기간과 시스템을 확인하지 못했는지 기록하면 다음 개선 과제가 바로 드러납니다: 보관 기간 연장, 로그를 다른 곳으로 전송, 제공자에게 문의. 이번 주 점검은 이상을 찾는 것만큼이나 자사가 얼마나 과거까지 볼 수 있는지 아는 데에도 목적이 있습니다.
직원과 고객을 위한 메시지
경찰청은 계속되는 유출을 언급하며, 기업에 인터넷에 연결된 장비를 최신 상태로 유지하고 강력한 비밀번호를 사용하라고 요청하고, 개인에게는 이메일 링크를 함부로 클릭하지 말고(유출한 기업을 사칭하는 가짜 이메일일 수 있음), 비밀번호를 재사용하지 말고, 다중 인증을 사용하라고 요청합니다. 사고 후에는 조직명을 사용한 가짜 메시지가 늘 수 있습니다. 직원과 고객에게 모든 연락은 공식 웹사이트를 통해 확인하라고 알리십시오. 피싱을 식별하는 방법은 피싱이란 무엇입니까?를 참고하십시오.
출처 (공식, 일본어)
- 내각관방 국가사이버보안실: 무단 접근에 의한 데이터 유출에 대한 대응(2026년 10월 9일) — cyber.go.jp
- IPA: 무단 접근에 의한 데이터 유출을 고려한 신속한 조치(2026년 10월 9일, 필요에 따라 갱신) — ipa.go.jp
- IPA: 무단 접근 특별 상담창구 개설(2026년 10월 16일, 일본어) — ipa.go.jp
- IPA: 무단 접근 대응 특별 사이트(2026년 10월 16일, 일본어) — ipa.go.jp
- JPCERT/CC: 일본 조직에서 발생한 최근 일련의 무단 접근 사고에 대한 경고(JPCERT-AT-2026-0030, 2026년 10월 8일 발표, 10월 23일 갱신) — jpcert.or.jp
- JPCERT/CC: 일련의 무단 접근 사례에서 사용된 공격 기법 조사(JPCERT/CC Eyes, 2026년 10월 15일, 일본어) — blogs.jpcert.or.jp
- 개인정보보호위원회: 대규모 정보 유출 대응(경고)(2026년 10월 7일; 해설 동영상 10월 9일 추가) — 공지 페이지 / 경고 및 별첨(PDF) / 보도자료(PDF)
- 개인정보보호위원회: WARNING: 무단 접근으로 인한 개인정보 유출 방지(2024년 12월 11일, 2026년 10월 7일 개정) — ppc.go.jp
- 금융청: 현재 상황에서의 사이버보안 강화 및 계좌 개설 처리(2026년 10월 9일) — fsa.go.jp
- 경찰청: 사이버 경찰 기관 서한 2026 Vol.19(2026년 10월) — npa.go.jp
- JPCERT/CC: 사고 대응 요청 — jpcert.or.jp
- IPA: 컴퓨터 바이러스 및 무단 접근 신고 — ipa.go.jp
일본 보안 기업의 분석(공식 문서 아님, 일본어):
- Macnica Security Research Center: 웹 시스템에서 발생한 일련의 데이터 유출에 대하여(2026년 10월 7일, 추가 기록 10월 8일) — security.macnica.co.jp
- GMO Cybersecurity by IERAE: 일련의 무단 접근 사고에 대비하기 위한 세 가지 요점(2026년 10월 15일) — gmo-cybersecurity.com
- GMO Cybersecurity by IERAE: 최근 무단 접근의 여러 출처 뒤에 AI가 있음을 확인(2026년 10월 19일, 10월 21일 갱신) — gmo-cybersecurity.com
업데이트 기록
2026-10-24: 10월 23일 갱신된 JPCERT/CC 경고를 반영했습니다. 공격 패턴이 4개에서 5개로 늘어났습니다(사례 E: 인터넷에 노출된 WSUS 서버에 대한 시도를 포함해 AI 기반 침투 테스트 플랫폼을 악용하는 공격 시도). 사례 B의 새로운 단서(공개 앱과 같은 User-Agent, JA4만으로는 공격자를 식별할 수 없음, Tor 및 주거용 프록시를 통한 접근, 과거 접근을 찾기 위한 IP 주소 활용)를 추가했습니다. AI 기반 공격 개요와 방어 순서 링크를 추가했습니다.
2026-10-23: 일본 보안 기업 두 곳의 분석(10월 7일, 15일, 19일)을 추가했습니다. 7월 이후 공개된 유출의 80%는 공지만으로 원인별 분류가 불가능하다는 내용, WAF 임계값 아래에 머무는 공격, AI 기반 자율 침투 테스트 시스템의 사용, 세 가지 점검(평가 범위, WAF 의존 금지, 불필요한 데이터와 API 키 축소)을 포함합니다.
2026-10-22: JPCERT/CC의 공격자 서버 조사(10월 15일 발표)를 추가했습니다. 앱 분석을 통해 식별된 API와 네 가지 대응책을 포함합니다. JPCERT/CC의 예시에 따라 컴파일된 앱의 예로 Flutter를 명시했습니다.
2026-10-19: IPA의 무단 접근 특별 상담창구(10월 16일 개설)와 특별 사이트를 추가했습니다. 10월 19일 기준 IPA의 10월 9일 경고가 갱신되지 않았음을 확인했습니다.
2026-10-14: PPC 경고의 본문을 확인하고, 2027년 4월 확정 예정인 "10-6 기술적 안전조치" 개정 예시 별첨을 표로 요약했습니다. 개정된 WARNING의 사례 9(API 악용)의 대응책을 인터넷 노출 앱 점검에, 사례 8(사용 중인 클라우드 서비스에서의 유출)을 외부 서비스 점검에 추가했습니다. 문서 목록과 출처를 갱신했습니다.
2026-10-12: 최초 공개. 2026년 10월 12일 기준으로 국가사이버보안실, IPA, JPCERT/CC, PPC, 금융청, 경찰청 문서를 확인했습니다. IPA 페이지는 필요에 따라 갱신되고 JPCERT/CC 경고에는 추가 내용이 올라올 수 있으며, 변경되면 이 기사도 갱신됩니다.
다음으로 읽기
- AI 기반 공격의 전체 그림과 방어 순서: AI 기반 사이버 공격에 대한 방어(자율 침투, 프롬프트 인젝션, AI 공급망)
- 조직을 위한 더 큰 그림: 조직을 위한 보안 기준선(2026년 일본 사고에서 얻은 여섯 가지 우선순위)
- 자사 사이트 점검: 웹사이트나 서버가 해킹되었는지 확인하는 방법
- 진입점: VPN 장비가 가장 큰 진입로입니다 / CVSS, EPSS, KEV로 우선순위 정하기
- 목록화: 보안 자산 목록 점검표 / 클라우드 스토리지 공개 노출
- 용어: IOC란 무엇입니까?
- 2026년 전체 사고: 2026년 데이터 유출과 사이버 공격