Privacy Desk

보안이나 개인정보 업무는 결과물이 눈에 잘 안 보이는 편이다.그래서 이직 준비를 하면서도 “내가 뭘 했는지”를 설명하기가 어렵다고 느끼는 사람이 많다.그런데 실무에서는 오히려 문서가 실력을 보여주는 경우가 많다.특히 정합성이 있는 문서는 그 사람의 사고방식을 그대로 드러낸다.정합성이란 결국 “앞뒤가 맞는 구조”다정합성이 없는 문서는 대체로 이런 특징이 있다.수집 목적과 항목이 연결되지 않는다보유기간이 근거 없이 길거나 짧다보호조치는 나열돼 있지만 실제 적용 위치가 없다접근권한은 “통제”라고 적혀 있지만 역할 구분이 없다반대로 정합성이 있는 문서는서비스 흐름 → 데이터 흐름 → 리스크 → 보호조치가 자연스럽게 이어진다.실무에서 문서를 쓸 때 내가 잡는 기준문서 한 장만 봐도 처리 흐름이 그려지는가“왜 필요..

요즘 시스템은 API 중심으로 흘러간다.그래서 보안 점검에서도 “API 인증 붙였나요?”로 끝내면 안 되는 경우가 많다.API는 인증이 시작점이고, 실제 사고는 다른 지점에서 터지는 일이 많다.인증 다음에 봐야 하는 것: 인가(Authorization)인증은 “누구냐”를 확인하고, 인가는 “무엇을 할 수 있냐”를 정한다.API 사고는 보통 인가에서 나온다.본인 데이터만 조회해야 하는데 다른 사용자 데이터가 조회되는 경우역할에 따라 접근 범위가 달라야 하는데 통제가 느슨한 경우객체 단위 인가가 빠져서 ID만 바꾸면 다른 데이터가 보이는 경우실무에서는 이걸 “객체 수준 접근통제” 관점으로 반드시 체크한다.속도 제한과 남용 방지: Rate Limit은 보안이다API는 공격자가 자동화하기 좋은 구조다.그래서 다..

개인정보 보호에서 보유기간 준수는 기본이라고 말하지만, 막상 운영을 들여다보면 가장 자주 틀어지는 영역이 보유·파기다.“파기 정책이 있다”와 “실제로 파기된다”는 다르다.특히 서비스가 커질수록 개인정보가 한 곳에만 있지 않기 때문에, 보유기간은 더 어려워진다.개인정보는 DB에만 있지 않다실무에서 보유·파기를 어렵게 만드는 건 데이터의 분산이다.운영 DB로그(접속/행위/오류)백업/스냅샷데이터 레이크/분석 플랫폼고객센터 티켓/첨부파일DB에서 지웠는데 분석 환경에 남아 있거나, 백업에 남아 있으면 “완전한 파기”라고 말하기 어렵다.보유기간은 목적별로 쪼개야 실행된다하나의 개인정보라도 목적이 다르면 보유기간이 달라진다.서비스 제공 목적분쟁 대응 목적법정 보관 목적보안 감사 목적(접속 기록)그래서 실무적으로는 “..

취약점 관리는 도구만 도입하면 해결될 것 같지만, 운영을 해보면 가장 어려운 건 “무엇부터 고칠지”를 결정하는 일이다.현업은 늘 바쁘고, 패치는 서비스 중단 위험도 있다. 그래서 취약점은 쌓이고, 어느 순간부터는 목록만 늘어난다.결국 취약점 관리는 스캐너보다 우선순위 체계가 핵심이라고 느낀다.CVSS 점수만으로 우선순위를 정하면 어긋나는 경우가 많다CVSS는 중요한 지표지만, 실제 영향도는 환경에 따라 달라진다.외부 노출 시스템인지(인터넷 공개 여부)공격 난이도(인증 필요 여부, 익스플로잇 존재 여부)자산 중요도(개인정보/결제/인증 여부)보완 통제 존재 여부(WAF 룰, 네트워크 차단, 권한 분리)그래서 점수만 보고 “높다/낮다”로 처리하면, 실제 위험한 것부터 놓칠 수 있다.실무에서 쓰기 좋은 우선순위..

개인정보 보호를 얘기할 때 암호화나 접근통제 같은 기술 조치가 먼저 떠오르지만, 실무에서 사고의 시작점은 의외로 위탁(수탁) 구간인 경우가 많다.내부에서 아무리 통제를 잘해도, 외부 업체가 처리하는 구간이 느슨하면 전체 리스크가 그쪽으로 새어 나간다.위탁 관리는 “계약서 한 장”으로 끝나지 않는다.오히려 계약 이후에 운영을 어떻게 굴리느냐가 핵심이다.위탁을 명확히 정의하지 않으면 통제가 시작되지 않는다가장 먼저 정리해야 하는 건 “이게 위탁인가?”다.단순 구매(라이선스/솔루션)인지운영대행(계정 접근/원격 접속)이 포함되는지데이터 처리(수집·보관·가공)를 실제로 수행하는지이 경계가 애매하면, 수탁사 접근권한·재위탁·파기 책임도 흐려진다.그래서 사전 검토에서부터 업무 흐름을 기준으로 위탁 여부를 먼저 확정하..

처음엔 문서 작업이 번거롭다고 느꼈다.그런데 실무를 하다 보니 생각이 조금 바뀌었다.보안과 개인정보 업무에서 문서는 단순한 보고서가 아니라,의사결정의 근거운영의 기준사고 대응의 기록이 되기 때문이다. 문서는 ‘감사 대비용’이 아니라 ‘운영용’이다정책이나 절차 문서가 감사 대비에만 쓰이면,감사가 끝난 뒤엔 다시 서랍 속으로 들어간다.하지만 운영 문서로 만들면 다르다.예:예외 권한 승인 기준로그 보관기간과 접근 절차위탁사 점검 체크리스트영향평가 시 확인해야 할 항목과 증빙이런 문서는 실제 운영에서 계속 쓰인다.특히 사람이 바뀌어도 일이 이어지게 만드는 힘이 있다.보안 업무는 ‘말’보다 ‘기준’으로 움직일 때가 많다보안 담당자가 아무리 열심히 설명해도,기준이 없으면 결국 사람마다 판단이 달라진다.그래서 나는 ..

개인정보 유출 사고를 생각하면 보통차단포렌식복구같은 기술 대응을 떠올리게 된다.물론 중요하다.하지만 실제로 대응 단계에서 더 크게 흔들리는 건 기술이 아니라 “정리되지 않은 사실관계”인 경우가 많다.그래서 나는 유출 대응을 준비할 때 기술보다 먼저 정리해야 하는 것이 있다고 느낀다.‘무슨 일이 있었는지’를 증명할 수 있어야 한다사고가 발생하면 가장 먼저 필요한 건 결론이 아니라 기록이다.어떤 시스템에서어떤 계정으로언제부터 언제까지어떤 데이터가어떤 경로로이게 정리되어야 대외적으로도 말이 맞고, 내부 대응도 흔들리지 않는다.그래서 평소에 사고 대응 준비를 한다면,가장 먼저 아래를 점검하는 게 좋다고 본다.접근로그가 남는가(누가, 언제, 무엇에)로그 보관기간이 충분한가(조사에 필요한 기간)로그가 변조되지 않게..

요즘 보안 트렌드에서 빠지지 않는 키워드 중 하나가 공급망 보안이다.특히 오픈소스와 외부 라이브러리에 의존하는 구조가 당연해지면서, “우리 코드가 안전한가”보다 “우리 코드가 끌어오는 구성요소가 안전한가”가 더 중요해지는 상황을 자주 마주한다.이 흐름 속에서 SBOM(Software Bill of Materials) 이야기가 계속 나오는 이유도 여기에 있다고 본다.취약점은 ‘우리 시스템’이 아니라 ‘우리 의존성’에서 터질 때가 많다개발을 직접 하지 않아도,프레임워크패키지 매니저이미지 베이스(컨테이너)CI/CD 플러그인같은 요소가 침해 경로가 될 수 있다.문제는 이런 요소들이 많아질수록 “내가 무엇을 쓰고 있는지”조차 모르는 상태가 되기 쉽다는 점이다.그래서 구성요소 목록 자체가 보안 통제의 출발점이 된다..

보안 솔루션을 도입하는 것보다, 계정과 권한을 정리하는 게 더 어렵고 더 중요하다는 말을 실무에서 자주 느낀다.실제 사고 사례를 보면 침해의 시작점이 “취약점”인 경우도 많지만, 확산과 피해 규모는 “권한”이 결정하는 경우가 많다.그래서 보안 담당자 입장에서 가장 먼저 기본기를 점검한다면, 나는 IAM(Identity and Access Management)을 꼽고 싶다.권한은 ‘누가 뭘 할 수 있나’가 아니라 ‘누가 뭘 못 하게 할 건가’다권한 체계가 흔들리는 조직에는 몇 가지 공통점이 있다.계정이 역할이 아니라 사람 단위로 부여된다예외 권한이 회수되지 않는다관리자 권한이 너무 넓게 퍼져 있다시스템별로 계정 체계가 제각각이라 통제가 어렵다이 상태에서는 보안 점검을 해도 체감 개선이 잘 안 된다.왜냐하면..

개인정보 업무를 하다 보면 “영향평가(PIA)부터 쓰자”는 흐름으로 시작하는 경우가 많다.그런데 막상 문서를 쓰기 시작하면 가장 먼저 막히는 지점이 생긴다.어디서 수집되고, 어디로 흘러가고, 어디에 저장되며, 누가 접근하는지이 흐름이 머릿속에 정리되어 있지 않으면 문서가 계속 ‘조항 나열’처럼 되어 버린다.그래서 나는 영향평가든 점검이든, 가능하면 먼저 개인정보 처리흐름(데이터 맵)을 잡는 편이 더 효율적이라고 느낀다.데이터 맵이 있으면 “무엇이 문제인지”가 훨씬 구체적으로 보이기 때문이다.데이터 맵이 있어야 리스크가 보인다개인정보 리스크는 대부분 “항목 자체”보다 “흐름”에서 나온다.예를 들어 같은 이메일 주소라도,서비스 A에서는 로그인 식별자이고서비스 B에서는 마케팅 타깃팅 키로 쓰이고서비스 C에서는..