Samsung SDS

1. 로그인 이후에 피해가 커지는 이유

예전에는 회사 네트워크 바깥에서 들어오는 접속을 막는 것이 보안의 중심이었습니다. 방화벽으로 허가되지 않은 접근을 차단하고, 외부 근무자는 VPN으로 사내 시스템에 접속했습니다. 공격자를 회사 네트워크 안에 들이지 않는 것이 중요한 과제였습니다.

지금은 직원들이 사내 시스템 외에도 클라우드, SaaS(인터넷으로 이용하는 소프트웨어), 협업 도구를 사용합니다. 사무실뿐 아니라 집이나 출장지에서도 접속합니다. 자료와 권한이 여러 시스템에 나뉜 만큼, 네트워크 접속 기록만으로는 계정을 탈취한 사람이 로그인 뒤 어디까지 들어갔는지 알기 어렵습니다.

피싱으로 직원 한 명의 아이디와 비밀번호가 유출됐다고 가정해 보겠습니다. 공격자가 이 정보로 로그인하면 기록에는 정상 계정의 접속이 남습니다. 그 계정의 권한에 따라 진행 중인 계약, 담당자와 협력사 연락처, 결재 일정 등을 확인하고 공유 문서나 다른 업무 시스템에도 접근할 수 있습니다. 인사·재무·고객 정보에 대한 권한까지 있다면 조사해야 할 범위는 더 넓어집니다.

이때 최초 로그인 기록만으로는 피해 범위를 알 수 없습니다. 그 계정에 어떤 권한이 있었는지, 로그인 뒤 어느 시스템에 들어갔는지, 이상 접속을 언제 알아챘는지를 함께 확인해야 합니다. 접속 정보는 피싱뿐 아니라 서버나 협력업체 PC에 저장된 상태에서도 탈취될 수 있습니다.

서버와 협력사 PC에 저장된 접속 정보

2025년 SK텔레콤 침해사고에서 민관합동 조사단은 전체 서버 4만 2,605대를 점검해 공격받은 서버 28대를 확인했습니다.^[1] 공격자는 외부와 연결된 서버에 악성코드를 설치했습니다. 조사단은 그 서버에 암호화되지 않은 채 저장돼 있던 계정 정보로 다른 서버에 접속했을 것으로 추정했습니다. 다른 서버에 저장된 계정 정보를 이용해 음성 통화 인증 관리 서버에 접속한 사실은 확인했습니다. 여러 서버의 계정 정보와 접속 기록을 이어 봐야 이동 경로가 드러난 사고였습니다.

법인 보험대리점 사고는 고객사 바깥에서 시작됐습니다. 한국인터넷진흥원(KISA)의 2025년 상반기 보고서에 따르면, 협력사의 PC가 악성코드에 감염되면서 PC에 저장된 고객사 시스템 접속 정보가 탈취됐습니다.^[2] 공격자는 이 정보로 고객사 시스템에 침투했습니다. 고객사가 협력업체에 발급한 계정이라도 접속 정보를 어디에 보관하는지, 업무가 끝난 뒤 계정을 누가 회수하는지 확인해야 하는 이유입니다.

두 사고에서 공격자가 다음 시스템으로 이동할 때 사용한 것은 서버나 협력사 PC에 보관돼 있던 접속 정보였습니다. 피해 범위를 파악하려면 최초 침투 지점에 더해 그 정보가 보관된 위치, 계정의 권한, 실제로 접근한 시스템을 따라가야 합니다. 이동을 막으려면 탈취한 정보가 어느 로그인 경로에서 사용될 수 있는지도 살펴야 합니다.^[3]

[그림1] SK텔레콤·법인 보험대리점 사고에서 계정 정보가 사용된 경로 (출처: 삼성SDS)

접속 정보가 사용된 두 경로

SK 텔레콤: 외부 연결 서버 침투 → 관리 계정 정보 이용 → 다른 서버에 접속
법인보험대리점: 협력사 PC 감염 → 고객사 접속 계정 탈취 → 고객사 시스템 침투

2. 공격을 멈추는 지점, MFA와 SSO

비밀번호만 확인하는 시스템이라면 공격자는 유출된 정보로 로그인을 시도할 수 있습니다. MFA(Multi-Factor Authentication, 복합 인증)는 이때 비밀번호 외에 문자 인증 번호, OTP 앱, 생체인증, 보안키 등으로 사용자를 한 번 더 확인합니다. 공격자가 비밀번호를 알아도 추가 인증을 통과하지 못하면 로그인이 제한됩니다.

접속 상황에 따라 추가 인증을 요구할 수도 있습니다. 예를 들어 평소와 다른 기기나 낯선 위치에서 로그인하면 직원의 휴대폰으로 승인 요청을 보내는 방식입니다. 본인이 시도하지 않은 접속이라면 직원은 요청을 거절하고 보안 담당자에게 알릴 수 있습니다.

[그림2] 비밀번호가 유출됐을 때 MFA 적용 여부에 따른 로그인 흐름 (출처: 삼성SDS)

비밀번호 유출 이후, 로그인은 어떻게 달라질까요?

유출된 아이디 · 비밀번호로 로그인 시도

MFA 미적용 - 비밀번호가 맞으면 로그인 가능

MFA 적용 - 추가 인증에 실패하면 로그인 차단

MFA가 빠진 로그인 경로

메일에는 MFA를 적용했지만, 오래된 전자결재 시스템에는 비밀번호 로그인만 남아 있을 수 있습니다. 협력사 계정이나 임시 계정이 인증 예외로 등록된 경우도 있습니다. 공격자는 비밀번호를 확보한 뒤 추가 인증을 요구하지 않는 경로에서 접속을 시도할 수 있습니다. 사고가 나면 시스템마다 흩어진 로그인 기록을 맞춰 봐야 한다는 어려움도 있습니다.

SSO로 인증 기준을 맞추기

SSO(Single Sign-On, 통합 로그인)는 직원이 회사 계정으로 인증한 뒤 연동된 업무 시스템을 이용하도록 로그인 경로를 연결합니다. 회사는 SSO를 거치는 로그인에 MFA 정책을 적용하고, 연동된 시스템의 인증 기준을 관리할 수 있습니다.

[그림3] 시스템별 로그인 방식과 SSO·MFA를 통한 통합 접속 관리 비교 (출처: 삼성SDS)

SSO · MFA 적용 전후의 로그인 경로

적용 전 - 시스템별 로그인

메일,전자결재,업무 시스템 각각 개별 로그인

인증 정책 • 로그인 기록이 시스템별로 분산

적용 후 - 통합 접속 관리

회사 로그인 - 정책에 따라 MFA[SSO] - 메일,전자결재,업무 시스템 통합이용 가능

연결된 서비스의 인증 정책 · 로그인 기록 관리

사고 조사에서는 기록의 범위를 구분해야 합니다. SSO 인증 기록에서는 연동된 서비스에 대한 인증 이력을 확인할 수 있습니다. 로그인 뒤 어떤 파일을 열거나 내려받았는지는 해당 서비스의 활동 기록을 봐야 합니다. 두 기록이 각각 어디에 남는지 알아야 계정이 실제로 어디까지 사용됐는지 확인할 수 있습니다.

3. 로그인 다음에 남는 문제, 계정과 권한

SSO와 MFA로 로그인 경로를 정비해도 계정에 남은 권한까지 저절로 정리되지는 않습니다. 부서를 옮긴 직원이 이전 업무 시스템에 계속 접근할 수 있고, 프로젝트가 끝난 임시 계정이나 퇴사자 계정이 살아 있기도 합니다. 관리자 계정 하나를 여러 사람이 함께 쓰면 접속 기록이 있어도 실제 작업자를 확인하기 어렵습니다. 로그인 정책과 계정 변경·회수 절차를 함께 관리해야 하는 이유입니다. 이를 위해서는 계정의 발급부터 변경·회수까지의 이력과 시스템별 권한 현황을 함께 확인할 수 있어야 합니다. 통합 인증과 계정관리 솔루션은 이러한 관리 절차를 운영하는 데 활용할 수 있습니다. 삼성SDS의 SingleID는 계정과 권한 관리, 통합 인증, 복합 인증 등 관련 기능을 제공합니다.

SingleID가 맡는 계정 및 인증 관리

삼성SDS의 SingleID는 로그인과 계정관리에 필요한 기능을 다음과 같이 제공합니다.^[4]

• 계정관리(IM)는 계정과 권한의 생성·변경·회수를 관리합니다.
• 통합 인증(AM)은 연동된 서비스의 로그인을 연결합니다.
• 복합 인증(MFA)은 정해 둔 접속 구간에서 추가 인증을 요구합니다.
• 이상 인증 탐지(ADM)는 로그인 IP, 기기, 접속 시간 등을 바탕으로 평소와 다른 접속에 대응합니다.
• 클라우드 접근 관리(CAM)는 운영자와 개발자의 클라우드 콘솔·자원 접근을 역할에 따라 통제하고 작업 이력을 모니터링합니다.

[그림4] SingleID의 통합 인증·계정관리·복합 인증·이상 인증 탐지·클라우드 접근 관리 영역 (출처: 삼성SDS)

사용자(임직원,관계사,협력사,고객사) → SingleID 서비스(Samsung Cloud Platform) → 연동 업무 시스템(SaaS,사내 시스템,모바일) 및 클라우드 관리자(콘솔 • 자원)

SingleID 서비스(Samsung Cloud Platform)

로그인 • 추가 인증(AM 통합인증,MFA 복합인증)

계정 생성 · 변경 · 회수(IM 계정관리)

이상 로그인 확인(ADM 이상인증탐지)

클라우드 접근(CAM 클라우드 접근관리)

부서 이동이나 퇴사로 권한이 바뀌면 계정관리(IM)에서 계정과 권한의 변경·회수를 관리합니다. 통합 인증(AM)은 업무 시스템의 로그인을 연결하고, 복합 인증(MFA)은 필요한 접속 구간에 추가 인증을 적용합니다. 이상 인증 탐지(ADM)는 로그인 IP·기기·접속 시간에 따른 이상 징후를 살핍니다. 클라우드 접근 관리(CAM)는 운영자·개발자의 클라우드 콘솔·자원 접근을 통제하고 작업 이력을 모니터링합니다.

법인 보험대리점 사고처럼 협력사가 보관하던 접속 정보가 유출되면 고객사는 해당 계정이 어느 시스템에 접근할 수 있는지부터 확인해야 합니다. 계정을 누구에게 발급했고, 어떤 권한을 줬으며, 아직 사용할 수 있는 상태인지가 조사 대상입니다. 평소 IM을 통해 발급과 회수 상태를 관리해야 하는 이유도 여기에 있습니다.

4. 도입은 목록 대조부터

먼저 계정 목록과 시스템 목록을 나란히 놓습니다. 관리자·협력사·임시·클라우드 관리자 계정의 소유자와 권한, 최근 접속일, MFA 적용 여부를 살펴봅니다. 시스템별로는 SSO 연동 여부와 기존 아이디·비밀번호로도 로그인할 수 있는지를 확인합니다. 이 과정에서 담당자가 없는 계정과 추가 인증 없이 접속 가능한 경로가 드러납니다.

우선순위는 관리자 계정과 외부 접속입니다. 관리자 계정은 시스템 설정이나 다른 계정의 권한을 바꿀 수 있고, 외부 접속이 허용된 시스템에는 회사 밖에서도 로그인 시도가 들어옵니다. 이 구간의 MFA 적용 상태를 먼저 확인한 뒤 메일, 전자결재, 인사·재무 시스템, 주요 SaaS로 SSO 연동 범위를 넓힐 수 있습니다. 시스템을 연결할 때는 계정을 누가 만들고 회수하는지, 로그인 기록과 서비스 활동 기록이 어디에 남는지도 함께 확인합니다.

바로 연동하기 어려운 오래된 시스템과 임시·공유 계정은 예외 목록에서 관리합니다. 책임자, 사용 이유, 접근 범위, 만료일과 재검토 시점이 있어야 계정이 남아 있는 이유를 나중에도 확인할 수 있습니다. 필요한 경우 접속 IP나 사용 기간을 제한할 수도 있습니다.

이상 접속을 발견한 뒤 누가 대응할지도 정해져 있어야 합니다. 새 기기에서 관리자 계정으로 로그인하면 추가 인증을 요구할지, 반복해서 로그인에 실패한 계정은 언제 잠글지, 알림을 받은 담당자는 누구에게 확인할지를 미리 정합니다. 탐지 기록이 있어도 사용자 확인이나 접근 차단으로 이어지지 않으면 대응은 늦어집니다.

맺으며

사고가 난 뒤 확인해야 할 것은 로그인 성공 여부만이 아닙니다. 그 계정에 당시 어떤 권한이 있었고, 어느 시스템에 접속했으며, 사용 기록은 어디에 남았는지가 피해 범위를 결정합니다. 평소 계정과 시스템 목록을 맞춰 두는 일은 사고가 발생했을 때, 이 질문에 답하기 위한 준비입니다.

References

• 과학기술정보통신부, 「SK텔레콤 침해사고 최종 조사결과 발표」, 2025. 7. 4.
• 한국인터넷진흥원, 「사이버 위협 동향 보고서(2025년 상반기)」, 2025. 8. 7.
• 금융감독원·금융보안원 외, 「GA 개인정보 침해사고(해킹) 발생 경과 및 향후 계획」, 2025. 5. 20.
• 삼성SDS, 「SingleID | 통합인증 및 계정관리」.

FAQ