보안은 개발만의 영역이 아니다
PM이 기획 단계부터 설계해야 할 '최소 권한의 원칙'
최근 쿠팡을 비롯한 대형 플랫폼들의 잇따른 개인정보 유출 사고는 우리에게 큰 충격을 주었습니다. 특히 이번 사고들이 외부 해킹뿐만 아니라 내부자의 권한 관리 실패나 퇴사자 프로세스의 허점에서 비롯되었다는 점은 시사하는 바가 큽니다. 많은 사람들이 보안은 개발팀이나 보안팀의 전유물이라고 생각하기 쉽지만, 사실 가장 강력한 보안은 코드를 짜기 전 기획 단계에서부터 시작됩니다.
오늘은 PM이 기획서 한 줄로 수천만 건의 정보 유출을 막을 수 있는 'Privacy by Design'과 '최소 권한의 원칙'에 대해 이야기해 보려 합니다.
데이터 다이어트: 필요 없는 정보는 수집하지 마라
PM으로서 보안 사고를 예방하기 위해 가장 먼저 실천해야 할 원칙은 '필요 없는 정보는 애초에 수집하지 않는 것'입니다. 우리는 흔히 마케팅이나 미래의 활용 가능성을 염두에 두고 "일단 주소도 받고, 생년월일도 받아두자"는 유혹에 빠지기 쉽습니다. 하지만 수집된 모든 데이터는 곧 '잠재적인 유출 리스크'가 됩니다. 기획 단계에서 "이 정보가 서비스 제공에 정말 필수적인가?"를 치열하게 질문해야 합니다.
예를 들어, 실물 배송이 없는 디지털 서비스라면 주소 수집을 과감히 제외하고, 본인 확인이 꼭 필요 없다면 전화번호 대신 이메일 인증만으로 가입하게 하는 식입니다. 가지고 있지 않은 데이터는 유출될 수도 없기에, 데이터 다이어트는 가장 확실한 보안 대책이 됩니다.
내부자도 믿지 마라: 역할 기반 접근 제어(RBAC)의 설계
데이터 수집만큼 중요한 것은 수집된 데이터를 '누구에게, 얼마나 보여줄 것인가'를 설계하는 것입니다. 이번 쿠팡 사태에서도 드러났듯, 내부 직원에 의한 유출은 가장 막기 힘든 위협 중 하나입니다. PM은 어드민(관리자) 페이지를 기획할 때, 모든 운영자가 모든 고객 정보를 볼 수 있게 만드는 '프리패스' 설계를 경계해야 합니다. 대신 철저한 '역할 기반 접근 제어(RBAC)'를 도입해야 합니다.
CS 담당자에게는 상담에 필요한 전화번호만, 배송 담당자에게는 주소만 노출되도록 권한을 쪼개고, 그마저도 주민등록번호나 계좌번호 같은 민감 정보는 반드시 별표(*)로 마스킹 처리하여 불필요한 노출을 원천 차단해야 합니다. "편의상 다 열어두죠"라는 한순간의 안일한 기획이 나중에는 돌이킬 수 없는 사고의 구멍이 될 수 있음을 명심해야 합니다.
보안은 가장 기초적인 '기능(Feature)'이다
결국 보안은 나중에 덧붙이는 부가 기능이 아니라, 제품의 신뢰성을 지탱하는 가장 기초적인 기능(Feature)입니다. 화려한 기능을 기획하는 것보다, 고객의 소중한 정보를 안전하게 지키는 설계를 먼저 고민하는 것. 그것이 바로 이 시대가 요구하는 PM의 진짜 역량일 것입니다. 기획서의 체크리스트에 '보안'이라는 항목을 가장 위에 올려두는 것부터 시작해 보시길 바랍니다.
