사쿠라 인터넷 해킹 사태, 일본 클라우드 고객 136만 계정 정보 유출 위기

[핵심요약] 일본 대형 클라우드·호스팅 기업 사쿠라인터넷이 8월 9일 침입을 당해 렌탈서버 583개 계정이 무단 로그인됐고, 조사 중 영업관리시스템까지 뚫린 정황이 추가로 확인되며 최대 136만 계정의 정보 유출 위기로 커졌어요.

2026년 8월 9일, 일본의 대표 클라우드·호스팅 기업 사쿠라인터넷(さくらインターネット)의 내부 시스템에서 이상 징후가 포착됐어요. 조사 결과 공격자가 관리 환경을 거쳐 '사쿠라의 렌탈서버' 서비스 이용자 583개 계정에 무단 로그인하고, 일부 서버에 악성코드까지 설치한 사실이 드러났고요. 이 사건을 들여다보던 중 8월 19일에는 영업관리시스템까지 뚫린 정황이 추가로 확인되면서, 피해 범위가 최대 136만 563개 계정으로 크게 늘어났어요. 유출 우려 정보에는 회원 ID, 이름, 소속 회사·부서, 주소, 전화번호, 이메일, 생년월일, 성별, 가입 서비스와 계약 기간, 청구 금액까지 포함돼 있어요. 다행히 신용카드 정보는 저장하지 않는 구조라 결제 정보 유출 우려는 없다고 회사 측은 밝혔어요.

583개 계정에서 136만 계정으로, 사건이 커진 이유

처음 사쿠라인터넷이 공개한 내용은 '렌탈서버'라는 개별 상품 하나에 국한된 침해였어요. 공격자가 어떤 경로로 최초 진입했는지는 아직 공식적으로 밝혀지지 않았지만, 관리 환경을 경유해 고객 서버 583개 계정에 로그인하고 악성코드를 심는 데까지 성공했다는 점에서 단순 비밀번호 탈취를 넘어선 침투였다는 게 보안 업계의 해석이에요. 문제는 그다음이었어요. 이 사건을 조사하던 회사 포렌식팀이 전혀 다른 시스템인 '영업관리시스템'에서도 침해 흔적을 발견한 거예요. 이 시스템은 고객의 계약·청구 정보를 담고 있는, 렌탈서버와는 별개의 내부 업무 시스템이었는데, 공격자가 여기에도 접근할 수 있었던 정황이 나온 거죠. 결국 처음엔 '583개 계정' 규모였던 사건이 열흘 만에 '최대 136만 계정'이라는 훨씬 큰 사건으로 재정의된 셈이에요. 회사는 노출된 자격증명을 모두 무효화하고 악성코드를 제거했으며, 관계 당국에 신고하고 영향받은 고객에게 개별 통지를 진행 중이라고 밝혔어요. 다만 아직 실제 대량 유출이 확인된 건 아니고, 외부 전문기관과 함께 침입 경로와 영향 범위를 계속 조사하고 있는 단계예요.

왜 이 사건이 특히 위험한 사례인가?

이 사건이 눈여겨볼 만한 이유는 '피해 규모가 조사 도중 계속 불어났다'는 점이에요. 처음 공표된 583개 계정과 최종적으로 노출 가능성이 제기된 136만 계정 사이에는 2000배가 넘는 차이가 있어요. 이런 패턴은 사쿠라인터넷만의 특수한 사례가 아니라, 클라우드·호스팅처럼 여러 서비스가 하나의 관리 계정·백엔드 인프라를 공유하는 사업 구조에서 반복적으로 나타나는 위험이에요. 하나의 상품에서 시작된 침해가 관리 권한을 타고 전혀 다른 업무 시스템으로 옮겨가면, 처음 발표 시점엔 작아 보였던 사고가 나중엔 회사 전체 고객 데이터베이스급으로 커질 수 있다는 걸 보여준 사례인 거죠. 게다가 이번처럼 렌탈서버·호스팅 서비스 자체가 뚫리면, 그 위에서 운영되는 수많은 고객사 웹사이트·업무 시스템까지 연쇄적으로 영향을 받을 수 있다는 점도 중견기업 IT 담당자라면 특히 눈여겨봐야 할 대목이에요.

비슷한 조직이 대비하려면?

이런 유형의 사고를 막으려면 가장 먼저 '관리자 계정과 일반 서비스 계정의 권한 분리'가 필요해요. 하나의 관리 환경에서 여러 서비스·시스템에 동시에 접근할 수 있는 구조라면, 계정 하나만 뚫려도 피해가 눈덩이처럼 불어날 수 있거든요. 서비스별로 관리 권한을 쪼개고, 꼭 필요한 최소 권한만 부여하는 원칙을 지키는 게 기본이에요.

두 번째로는 '이상 로그인 탐지'예요. 583개 계정에 대한 무단 로그인이 실제로 감지된 건 결국 사후적으로 이상 징후를 포착했기 때문인데요, 평소와 다른 시간대·지역·기기에서의 로그인 시도를 실시간으로 잡아내는 체계가 있었다면 초기에 더 빨리 대응할 수 있었을 가능성이 커요.

세 번째로는 침해 사고 발생 시 '조사 범위를 넓게 잡는 습관'이에요. 이번 사건처럼 특정 상품 하나의 문제인 줄 알았던 사고가 조사를 진행하다 보니 완전히 다른 내부 시스템으로 번져 있었던 경우가 실제로 드물지 않아요. 사고 초기에 '이 정도면 됐다'고 조사를 서둘러 마무리하기보다, 관리 환경을 공유하는 다른 시스템까지 포함해 폭넓게 흔적을 훑어보는 게 나중에 훨씬 적은 비용으로 끝날 수 있어요.

• 여러 서비스·시스템이 같은 관리자 계정이나 백엔드 인프라를 공유하고 있는지 점검해 보세요.
• 최근 관리자 계정 로그인 로그에 낯선 시간대·IP·기기가 있는지 확인해 보세요.
• 고객 정보를 담은 영업관리시스템, CRM, 청구 시스템 등에도 별도의 접근 통제와 로그 모니터링이 적용돼 있는지 살펴보세요.
• 침해 사고 발생 시 조사 범위를 '문제가 생긴 그 시스템'으로만 한정하지 않고, 연결된 다른 시스템까지 넓혀서 점검하는 절차가 있는지 확인해 보세요.
• 비밀번호는 반드시 해시로 저장하고 있는지, 결제·카드 정보처럼 민감한 데이터는 애초에 최소한만 보관하고 있는지 재점검해 보세요.

Q. 우리 회사는 사쿠라인터넷 같은 클라우드·호스팅 기업이 아닌데도 관련이 있나요?

직접 클라우드 사업을 하지 않아도, 우리 회사가 쓰는 호스팅·SaaS·클라우드 서비스가 이런 식으로 뚫리면 그 위에 올라간 우리 데이터도 함께 위험해질 수 있어요. 외부 서비스를 쓸 때는 그 서비스가 침해당했을 때 우리 쪽 피해 범위가 어디까지인지 미리 가늠해 두는 게 좋아요.

Q. 전산 인력이 1~2명뿐인 중견기업도 이런 사고를 막을 수 있나요?

인력이 적을수록 모든 시스템을 다 지키기보다 '가장 중요한 관리자 계정' 몇 개에 집중하는 게 현실적이에요. 관리자 계정에 다중 인증(MFA)을 걸고, 그 계정으로 어떤 시스템에 접근할 수 있는지부터 목록으로 정리해 두는 것만으로도 이런 유형의 확산형 사고를 크게 줄일 수 있어요.

Q. 신용카드 정보가 없으면 안심해도 되나요?

결제 정보가 없어도 이름·주소·전화번호·계약 내용 같은 정보만으로 피싱이나 사칭 공격에 악용될 수 있어요. 유출 정보에 금융 정보가 없다는 건 피해 강도를 낮춰줄 뿐, 위험 자체가 사라지는 건 아니에요.

이번 사쿠라인터넷 사건은 '작은 상품 하나의 침해'로 시작해서 열흘 만에 '136만 계정 규모의 사고'로 재정의된 사례예요. 아직 실제 대량 유출이 확정된 건 아니지만, 조사 범위가 계속 넓어지고 있다는 사실 자체가 클라우드·호스팅 인프라의 위험성을 잘 보여줘요. 우리 회사가 직접 클라우드 사업자가 아니더라도, 우리가 쓰는 외부 서비스 하나하나가 이런 확산형 사고의 출발점이 될 수 있다는 걸 기억해 둘 필요가 있어요.

이런 사고를 보면 결국 '관리자 권한 하나가 뚫렸을 때 얼마나 멀리까지 번지는가'가 피해 규모를 가른다는 걸 알 수 있어요. 백업 데이터만큼은 관리자 권한이 뚫려도 물리적으로 손댈 수 없는 구조로 따로 떼어두는 게 최후의 방어선이 되는데요, 이중 데이터 다이오드 방식으로 백업망을 물리적으로 분리하는 디포트리스가 바로 그 역할을 해줘요.