대상: 직원과 위탁사가 관여하는 기업·조직에서 보안의 '최소한'을 어디에 둘지 정해야 하는 분. 1인 개발자와 소규모 운영자는 1인 개발자·소규모 운영자를 위한 보안 베이스라인을 보세요. 이 글은 본 사이트가 각 조직의 공식 발표를 바탕으로 분석해 온 일본의 2026년 사고를 조직 차원의 대책으로 다시 역산한 것입니다. 공격 절차는 다루지 않습니다.
사고가 드러낸 6개의 구멍
아래는 모두 본 사이트가 각 조직의 공식 발표를 바탕으로 해설해 온 사건입니다(일본어·영어판에 상세 해설이 있습니다).
| 공표된 사실 | 드러난 구멍 | 조직의 최소한 |
|---|---|---|
| 일본 디지털청: VPN 장비의 취약점으로 침입. 기자회견에서는 순서대로 패치를 적용하던 중이었다고 설명 | 외부 노출 장비의 업데이트가 '대기 순번' | ① 침입구 장비를 기한을 정해 막는다 |
| 일본 디지털청: 유지보수 담당자 계정을 이용한 서버의 대량 파일 접근을 탐지 | 자사 직원이 아닌 계정의 권한과 감시 | ② 유지보수·위탁·퇴직자 계정을 좁힌다 |
| Aflac: 공격이 평소 이용과 같은 형태여서 즉시 탐지하지 못했고, 단시간 대량 조회를 감시·제어하는 기능이 부족 | 하나하나는 '정상'인 접근의 양 | ③ 양과 시간을 감시한다 |
| 사쿠라 인터넷: 판매 관리 시스템에 대한 무단 접근은 2023년 4월~2026년 3월. 재발 방지책에 로그 수집 범위와 보관 기간 재검토 | 알아차렸을 때 되짚을 수 없음 | ④ 로그를 되짚을 수 있는 기간만큼 남긴다 |
| Gyazo: 유출된 메타데이터는 주로 2019년 1월 이전의 것 | 필요 없어진 데이터를 계속 보유 | ⑤ 필요 없는 데이터를 갖지 않는다 |
| Adobe Commerce: 8월 11일 수정 공개, 44일 뒤 악용 확인(KEV 등재). 공지는 여전히 '우선순위 2, 악용 미확인' | 공개 시점의 우선순위를 믿고 미룸 | ⑥ KEV로 우선순위를 다시 매긴다 |
이 표를 읽는 법: 탓하는 표가 아니라 자사를 점검하는 표
각 조직은 침입당한 뒤 조사하여 원인과 재발 방지책을 공표했습니다. 본 사이트는 그 보고서를 남의 일이 아니라 '우리에게도 같은 구멍이 있는가'를 점검하는 표로 씁니다. 이 구멍들은 유난히 부주의한 조직만의 것이 아닙니다. KDDI의 사건처럼 벤더조차 몰랐던 취약점이 침입구가 된 사례도 있어, 침입구를 완벽히 막는다는 전제는 성립하지 않습니다. 그래서 ②~⑤의 '들어와도 퍼지지 않게' 하는 쪽이 최소한에 들어갑니다.
조직의 최소한 6가지와 각각의 '첫걸음'
① 외부에서 닿는 장비를 기한을 정해 막는다
VPN 장비, 원격 데스크톱 입구, 방화벽 관리 화면 등 인터넷에서 직접 닿는 장비를 목록으로 만들고 기종, 버전, 업데이트 책임자를 적습니다. 일본 경찰청 통계에서는 랜섬웨어 감염 경로의 유효 응답 92건 중 61건이 VPN 장비였습니다.
첫걸음: 목록의 각 장비에 '악용이 확인된 취약점(KEV)이 나오면 며칠 안에 막는가'를 숫자 하나로 정합니다. '순서대로 적용'하는 운영은 디지털청 사건과 같은 구조입니다.
② 유지보수·위탁·퇴직자 계정을 좁히고 보이는 곳에 둔다
어느 조직에나 직원이 아닌 사람의 계정, 즉 유지보수 업체, 위탁사, 이미 퇴직한 사람의 계정이 있습니다. 편의를 위해 넓은 권한을 받기 쉽고, 누가 관리하는지도 모호합니다.
첫걸음: 직원이 아닌 계정을 모두 목록으로 만들고 각각에 사내 담당자와 만료일을 붙입니다. 그다음 쓸 때만 활성화, 접속 출발지 제한, 피싱에 강한 2단계 인증 필수화를 차례로 진행합니다. 계정 정지는 입사 절차와 같은 서류에 올려 두세요.
③ '양'과 '시간'을 감시한다
Aflac 사건에서 공격은 평소 이용과 똑같은 형태였습니다. 조회 하나하나가 정상이라면 하나씩 검사해서는 막을 수 없습니다. 남는 단서는 시간당 몇 건이 빠져나갔는가와 심야·휴일의 움직임입니다.
첫걸음: 고객 데이터를 가장 많이 돌려주는 기능 하나에 계정당 시간당 상한과 상한의 80%에서 담당자에게 도착하는 알림을 붙입니다. 파일 서버와 클라우드 스토리지에는 평소의 몇 배에 이르는 일괄 다운로드에 알림을 설정합니다.
④ 로그를 '알아차렸을 때 되짚을 수 있는 기간' 남긴다
사쿠라 인터넷 사건에서 무단 접근은 약 3년 전부터 시작되었습니다. 그 기간의 로그가 없으면 무엇이 일어났는지도, 무엇이 일어나지 않았는지도 말할 수 없습니다.
첫걸음: 인증(성공과 실패), 데이터 조회와 출력, 관리 조작 세 종류만은 최소 12개월 남깁니다(결제 카드 업계 기준 PCI DSS를 기준으로). 용량이 부족하면 웹 접근 로그보다 이 세 종류를 먼저 지킵니다.
⑤ 필요 없어진 데이터를 갖지 않는다
Gyazo 사건에서 유출된 메타데이터의 중심은 몇 년 전에 업로드된 이미지의 부가 정보였습니다. 유출 규모는 그 시점에 갖고 있던 데이터의 양으로 정해집니다. 갖고 있지 않은 데이터는 유출되지 않습니다.
첫걸음: 고객 데이터의 종류마다 '무엇을 위해, 언제까지 갖는가'를 한 줄로 적습니다. 적을 수 없는 것은 삭제나 익명화의 후보입니다. 해지한 이용자의 정보가 계속 남아 있지 않은지도 확인하세요(사쿠라 인터넷 사건에서는 해지해도 탈퇴하지 않는 한 회원 정보가 보유되고 있었습니다).
⑥ 공개 시점의 평가가 아니라 KEV로 우선순위를 다시 매긴다
Adobe Commerce는 수정 공개 시 공지가 '우선순위 2, 악용 미확인'이었고, 44일 뒤 CISA가 악용을 확인했습니다. WordPress 본체의 경우 그 기간이 3일이었습니다.
첫걸음: 자사에서 쓰는 제품이 KEV에 추가되면 알림을 받는 구조를 하나 마련하고, 추가되면 '업데이트 순서'를 다시 매기는 규칙으로 만듭니다. 판단 절차는 CVSS·EPSS·KEV로 우선순위 정하기에 있습니다.
침입구를 좁힌다
① 외부 노출 장비를 기한을 정해 막는다 / ⑥ KEV로 우선순위를 다시 매긴다
들어와도 닿는 범위를 좁힌다
② 유지보수·위탁·퇴직자 계정 / ⑤ 필요 없는 데이터를 갖지 않는다
침입을 알아차리고 되짚을 수 있다
③ 양과 시간을 감시한다 / ④ 로그를 충분히 남긴다
개인과 조직에서 무엇이 달라지는가
조직에 쌓이는 것(사고는 여기서 시작된다)
- 자기 것이 아닌 계정(유지보수 업체, 위탁사, 퇴직자)
- 아무도 존재를 기억하지 못하는 장비(설치 업체에 맡긴 VPN, 오래된 검증 환경)
- 오랫동안 쌓인 데이터(해지한 회원, 오래된 메타데이터)
- '누군가 보고 있겠지' 하는 감시(도구는 있는데 담당자가 없음)
조직의 최소한에서 할 일
- 모든 것에 사내 담당자와 기한을 붙인다
- 외부 노출 장비는 목록과 업데이트 기한으로 관리한다
- 데이터는 가질 이유와 기간을 적고, 적을 수 없는 것은 지운다
- 알림은 숫자와 받는 사람을 정하고, 실제로 도착하는지 시험한다
본 사이트의 관점: 최소한이란 '누가, 어떤 숫자로, 언제 알아차리는가'를 정하는 것
사고 보고서를 나란히 놓고 보면 눈에 띄는 것은 많은 조직이 이미 보안 제품을 갖고 있었다는 점입니다. Aflac은 무단 접근을 탐지·차단하는 기능을 갖추고, 출시 전에 설계 검토와 침투 테스트도 실시했습니다. 그런데도 막지 못한 것은 공격이 예상했던 형태가 아니었기 때문입니다.
그래서 본 사이트는 조직의 최소한을 '무엇을 도입했는가'가 아니라 '누가, 어떤 숫자를 넘으면, 언제 알아차리는가'가 정해져 있는가로 재기를 권합니다. 도입한 도구 목록은 감사에는 도움이 되지만, 사고가 난 밤에 전화를 울리는 것은 기준값과 받는 사람이 정해진 알림뿐입니다. 알림이 아직 퇴직자의 메일 주소로 가고 있지 않은지 확인하는 것만으로도 첫걸음이 됩니다.
사람과 거버넌스 — 6가지를 계속 돌리기 위해
6가지 최소한은 한 번 하고 끝나는 것이 아닙니다. 담당자는 이동하고, 장비는 늘고, 데이터는 쌓입니다. 계속 돌리기 위한 토대로 최소한 다음을 갖추세요.
- 책임자 한 명을 정한다: 6가지 각각의 목록과 기한을 누가 갖고 있는가.
- 분기마다 한 번 점검: 장비, 직원이 아닌 계정, 데이터 목록을 갱신한다(방법은 자산 점검 체크리스트).
- 교육은 '연락을 확인하는 법'부터: 사고 직후에는 조직 이름을 사칭한 편승 연락이 반드시 늘어납니다. 직원과 고객 모두 공식 사이트에서 확인하는 습관을 들이게 하세요.
- 위탁사와의 계약에 계정과 로그의 취급을 적는다: 유지보수·위탁 경로는 계약에 정해 두지 않으면 아무도 관리하지 않습니다.
다음으로 읽기
- 판단: 어떤 CVE부터 고칠까 — CVSS·EPSS·KEV
- 계정: 어떤 2단계 인증이 가장 안전할까 / 자산 점검 체크리스트
- 개인·소규모판: 1인 개발자·소규모 운영자를 위한 보안 베이스라인
- 과거 사례: 베네세 개인정보 유출 사건(위탁사의 내부 부정) / KADOKAWA·니코니코 랜섬웨어 사건(분리 부족으로 전사 확산)
FAQ
Q조직의 보안 대책은 어디서부터 시작해야 하나요?
실제 사고에서 뚫린 곳부터 시작하는 것이 확실합니다. 일본의 2026년 대형 사고에서는 VPN 장비의 취약점(일본 디지털청), 유지보수 담당자 계정을 이용한 서버 파일 대량 접근(같은 사건), 단시간 대량 조회를 막지 못한 점(Aflac), 약 3년간 알아차리지 못한 무단 접근(사쿠라 인터넷) 등이 공표되었습니다. 본 사이트는 이를 바탕으로 외부 노출 장비, 유지보수·위탁 계정, 양의 감시, 로그 보관 기간, 갖지 않을 데이터, 우선순위 재조정의 6가지를 최소한으로 봅니다.
Q개인 개발자용 체크리스트와 무엇이 다른가요?
조직에는 자기 것이 아닌 계정(위탁사, 유지보수 업체, 퇴직자), 아무도 기억하지 못하는 장비, 오랫동안 쌓인 데이터가 늘어납니다. 사고의 상당수는 이런 '주인이 분명하지 않은 것'에서 시작됩니다. 개인판은 자신의 열쇠와 비밀을 지키는 이야기이고, 조직판은 주인 없는 것에 주인을 붙이는 이야기입니다.
QEDR이나 SIEM 같은 제품을 도입하면 충분한가요?
제품은 수단이지 최소한이 아닙니다. Aflac은 무단 접근을 탐지·차단하는 기능을 갖추고 있었지만, 접근 형태가 평소 이용과 같았기 때문에 즉시 탐지하지 못했다고 공표했습니다. 중요한 것은 '몇 건을 넘으면, 누구에게, 언제' 알림이 가는지 정하고, 실제로 도착하는지 확인하는 것입니다.
Q중소기업도 같은 일을 해야 하나요?
6가지 사고방식은 규모와 상관없습니다. 예산과 인력이 부족하다면 VPN 등 외부 노출 장비 목록과 업데이트 기한, 유지보수·위탁 계정 점검, 가장 많은 데이터를 돌려주는 기능 하나에 시간당 상한과 알림 설정, 이 세 가지부터 시작하세요.