Privacy Desk

2025년 하반기, 국내 이커머스 시장 최대 규모의 개인정보 유출 사고가 발생했다.쿠팡에서 약 3,370만 개 계정의 개인정보가 유출된 사건이다. 이름, 이메일, 휴대전화번호, 주소, 일부 주문정보 등이 유출 대상에 포함되었고,결제정보·카드번호·비밀번호는 직접적인 유출 범위에서 제외됐다고 발표되었다. 문제는 규모뿐 아니라,해외 서버를 통한 비인가 접근이 약 5개월간 지속되었는데도탐지가 지연되었다는 점이다. 1. 유출 경로 – “서버 인증 취약점”과 내부 키 관리 이슈과기정통부·개인정보위 발표를 종합하면,이번 사고의 직접적인 원인은“쿠팡 서버의 인증 취약점을 악용한 비인가 조회”로 정리된다. 핵심 포인트를 정리하면 다음과 같다. • 2025년 6월 24일경부터해외에 위치한 서버에서 쿠팡 시스템으로의..

React 19와 Next.js 15/16을 포함한 React Server Components(RSC) 생태계에서치명적인 원격 코드 실행(RCE) 취약점이 공개됐다.CVE-2025-55182, 일명 React2Shell로 불리는 이 취약점은RSC에서 사용하는 Flight 프로토콜의 역직렬화(deserialization) 결함으로 인해,인증 없이(pre-auth) 특수하게 조작된 요청만으로 서버 측에서 임의 코드를 실행할 수 있다. React 팀과 여러 보안 업체에서 CVSS 10.0(최고 심각도)로 평가하고 있고,기본 설정 상태의 Next.js 앱(단순 create-next-app 결과물)도코드 수정 없이 공격 대상이 될 수 있다는 점 때문에Log4Shell에 비견되는 이슈로 다뤄지고 있다. 1. 어..

정보보안 커리어를 어떻게 가져가야 할지는아직 저도 잘 모르겠다.주변에서 일하는 선배들, 동기들 얘기를 듣다 보면길이 정말 제각각이라“이게 정답이다”라고 말하기가 쉽지 않은 것 같다.그래도 몇 년 정도 현장에서 일하다 보니머릿속에서 대략 이렇게 나뉘어 보이는 부분이 있어서,어디까지나 개인적인 메모 느낌으로 한 번 정리해 본다.(틀릴 수도 있고, 상황마다 많이 다를 수 있다는 전제를 깔고 보고 봐 주면 좋겠다.)1. 초반 단계 – 운영·관제 쪽에서 “현상을 먼저 익히는 시기” 같았다저 포함해서 주변 얘기를 들어보면경력 초반에는 운영이나 관제 쪽에서 시작하는 경우가 꽤 있는 것 같다. • 시스템·네트워크 로그를 직접 보는 경험 • 장애나 알람이 났을 때 선배들이 어떤 순서로 확인하는지 옆에서 배우는 시간 • ..

개인정보 영향평가나 보안 점검을 여러 건 동시에 진행하다 보면“지금 뭐가 어디까지 되어 있는지” 현황을 정리하는 일 자체가 일이 된다.예전에 저는엑셀 파일 여러 개, 메일 스레드, 회의 메모를 왔다 갔다 하다가이걸 조금이라도 줄여보려고엑셀, 파이썬, 간단한 API 조합으로 현황 정리를 자동화해 본 적이 있다.1. 마스터 엑셀 정의: 프로젝트별 최소 필드만 정리먼저 한 일은“이력 관리의 기준이 될 엑셀”을 하나 만드는 거였다.각 평가·점검 건마다 다음 정도 필드를 두었다. • 고유 ID 또는 시스템명 • 담당 부서, 담당자 • 평가 유형 (신규, 정기, 사전검토 등) • 상태 (요청, 자료수신 중, 인터뷰 완료, 초안 작성, 검토 중, 완료 등) • 주요 일정 (요청일, 인터뷰일, 보고서 초안, 확정일)이..

사옥이전은 생각보다 “보안 프로젝트”에 가깝다.장비만 옮기는 일이 아니라,망 구조, 접근통제, 출입관리, CCTV, 서버 위치까지 한 번에 흔들리는 작업이기 때문이다.실제로 사옥이전 프로젝트를 경험하면서보안 담당자 입장에서 먼저 정리했던 포인트들을 적어본다.1. 네트워크 존 재설계와 인터넷 구간 계획사옥이전을 계기로네트워크 존을 다시 나누는 경우가 많다.저는 우선 이 관점부터 봤다. • 사무공간 사용자망, 서버망, 보안장비망, 게스트망, 회의실망 • 인터넷 직접 연결 구간, 전용회선·MPLS, 클라우드 연결 회선 • 기존 장비를 그대로 가져갈지, 이 기회에 교체·통합할지특히 인터넷 회선 컷오버(cut-over) 일정은업무 중단 시간과 직결되기 때문에,방화벽·라우터 정책 변경, DNS 변경, VPN 전환까..

가명정보를 실제로 도입한 뒤ISMS-P, ISO 27701 같은 인증 심사에서이를 어떻게 설명할지 고민하는 경우가 많다.논문과 실무를 함께 경험하면서심사·점검 자리에서 가명정보 활용을 설명할 때어떤 구조로 말을 꺼내면 이해가 조금 더 잘 되는지정리해 보려고 한다.1. 법·인증 프레임과의 연결부터 짚어주기먼저, 심사자가 서 있는 프레임을 맞춰준다. •개인정보보호법상 가명정보 정의와 처리 요건 •ISMS-P의 개인정보 라이프사이클(수집–이용–제공–보관–파기) •ISO 27701에서 말하는 PII controller/processor 역할이 세 가지가 교차하는 지점을간단한 그림이나 표로 보여주고“우리 조직의 가명정보 처리는 이 지점에 위치한다”는 설명을 먼저 한다.막연히 “가명처리를 하고 있다”고 말하기보다는..

면접에서도 자주 나오는 질문이“웹쉘 업로드 공격이 발생했을 때 어떻게 대응하겠냐”는 것이다.관제·운영 현장에서도 한 번쯤은 겪어보는 유형의 인시던트다.웹쉘(web shell)은공격자가 서버에서 임의 명령을 실행하기 위해업로드하는 스크립트 파일이다.PHP, JSP, ASP, WAR 등 형태는 다양하지만본질은 서버 측 RCE(Remote Code Execution)를 얻는 것이다.실제 관제·대응 흐름을 단계별로 정리해 보았다.1. 탐지 단계: 로그와 시그니처로 이상 징후 포착웹쉘은 흔히 다음 경로에서 포착된다. • WAF 로그:파일 업로드, 특이한 파라미터, 악성 패턴 탐지 • 웹 서버 로그(Apache, Nginx, IIS):.php, .jsp 등의 스크립트 파일에 대한 비정상적인 POST 요청 • EDR..

요즘 신규 서비스는 대부분 API를 중심으로 설계된다.웹·앱·파트너 시스템이 모두 같은 API를 사용하고,내부 백오피스까지 API에 의존하는 구조가 흔하다.그런데 API 설계 단계에서 개인정보와 프라이버시를 놓치면나중에 영향평가나 점검, 심지어 사고 대응까지모든 단계에서 설명이 어려워진다.실무에서 API 기반 서비스를 볼 때개인정보·프라이버시 관점에서 먼저 정리해 보는 지점을 적어본다.1. 엔드포인트별 데이터 맵핑: 무엇이 어디로 나가는지 먼저 그려보기가장 먼저 하는 일은엔드포인트별로 어떤 필드가 오고 가는지를 맵핑하는 것이다. • /user/login, /user/profile, /user/withdraw • /order/create, /order/list, /order/history • /partne..

보안·개인정보 업무를 하다 보면해야 할 일 목록은 계속 늘어나는데인력과 시간은 그만큼 따라오지 않는 경우가 많다.모든 이슈를 “중요하다”라고만 할 수는 없기 때문에결국 우선순위를 세워야 한다.실무에서 조금이라도 혼란을 줄여 보려고개인적으로 자주 썼던 기준 세 가지를 정리해 본다.규제·법적 리스크 기준: “문제가 생기면 바로 설명을 요구받는가”첫 번째로 보는 축은규제기관·감사·심사와 직결되는지 여부다.예를 들어,법령에서 명시적으로 요구하는 보호조치(암호화, 접근통제, 접속기록 보관 등)인증(ISMS-P, ISO27001 등)에서 필수 점검 항목사고 발생 시 대외 공지·신고 의무가 생기는 영역은 우선순위를 최대한 상단으로 올렸다.이 영역에서 이슈가 나면설명해야 할 대상이내부를 넘어 외부까지 넓어지기 때문에,..

보안 운영 자동화를 이야기하면사람들은 흔히 SOAR, 플레이북, 챗봇 같은거창한 그림부터 떠올린다.실제로는 그런 단계까지 가기 전에작은 자동화 몇 개만 잘 정리해도일상적인 운영 피로도가 눈에 띄게 줄어든다.보안·인프라 실무에서현실적으로 효과가 좋았던 자동화 출발점을몇 가지로 나눠서 정리해 본다.반복되는 리포트와 현황 집계부터 자동화하기가장 먼저 눈에 보이는 대상은주단위·월단위로 반복 작성하는 리포트들이다.예를 들어,방화벽/IPS/WAF 차단 로그 Top N계정 잠금·비밀번호 초기화 현황주요 자산 패치 적용률, 취약점 조치율DLP 정책 위반 건수, 승인/반려 통계이런 리포트는 대부분쿼리 → CSV/엑셀 → 정리 → 붙여넣기라는 패턴을 반복한다.이 부분은SIEM/로그 시스템의 스케줄러 기능Python 스크립..