19 개인정보 보호
FAQ, 개인정보 영향 평가, 보안 취약점 진단
FAQ
QA를 진행하면서 FAQ(Frequently Asked Questions)를 미리 작성하는 일도 버겁지만 병행해야 합니다. 이 역시 규모가 큰 그래서 User들이 서비스를 이용하면서 가장 많이 할 법한 질문들을 미리 답변 형태로 등록해 놓는 것인데요. 사전에 준비해 놓지 않아도 상관은 없습니다. 하지만 오픈하자마자(또는 중요 기능을 업데이트하자마자) 특히 규모가 큰 서비스일수록 바로 수많은 질문이 물밀듯 쏟아집니다. 오류가 아닌 이상 대부분이 비슷한 질문들이지요.
신규 서비스보다 기존에 잘 이용하던 서비스일수록 개선을 위한 업데이트를 진행하게 되는데 기존 UX에 익숙한 User들은 일단 다시 익히고, 적응해야 된다는 사실에 만족감보단 먼저 불편함을 느끼게 됩니다. 단순한 업데이트라면 이슈가 없겠지만 많이 바뀌거나 또는 엄청나게 많은 User들이 사용하던 서비스라면 위에서 언급했듯 CS(Customer Service)가 감당할 수 없을 정도로 쓰나미처럼 몰려올 수 있습니다.
학습된 습관을 무시할 수가 없기 때문입니다. 대외 서비스든, 대내 서비스이든 IT 업계 종사하는 사람들조차 익숙해진 솔루션과 프로세스에 변화를 가져오게 되었을 땐 한동안 적응의 시기를 거쳐야 합니다. 그리고 여기에서 오는 불평과 불만은 지속적으로 FAQ나 매뉴얼으로 안내하며 감내해야 합니다.
그래서 사전에 작성해 두면 좋은 것이 FAQ 또는 매뉴얼입니다. 시간 소모를 줄일 수 있습니다.
개인정보 영향 평가
실수로 또는 오용, 남용, 악용으로 인하여 개인정보 유출 사고가 빈번하게 발생하고 있습니다. 그래서 해마다 온오프라인으로 '정보 보안 교육'을 받기도 하고, 모의 사고 침해 훈련(EX. 사내 이벤트를 가장한 피싱 메일), 보안 캠페인, 관리 보안 점검(서랍 잠금, 노트북 시건장치 유무, 문서 방치 여부 등), 정보 보안 점검(자리비움 시 화면보호기 실행, 패스워드 기준 준수, 보안 프로그램 설치, PC 내 개인정보 파일 삭제 또는 암호화 등)을 실시합니다.
이처럼 개인정보 보호 기준이 점차 강화되면서 더불어 기획을 할 때도 준수해야 할 정책들이 많아졌는데 몇 가지 예를 들어 보겠습니다.
- 개인정보 처리 방침에 개인 정보 수집 항목, 수집 목적, 이용 기간(파기 시점)이 명시되어 있는가.
- 개인정보 처리 방침에 개인정보를 제3자에게 제공하는 경우 제공받는 자, 제공 목적, 제공 항목, 이용 기간이 명시되어 있는가.
- 개인정보 수집 및 이용 시 필수 항목과 선택 항목이 구분되어 있고, 선택 항목의 경우 미동의가 가능한가.
- 아이디 표기 또는 폰번호 표기 시 마스킹 처리가 되어 있는가.(EX. 010-XXXX-1234)
- 개인정보 접속 기록은 1년 이상(2019. 6. 7자로 6개월 -> 1년으로 늘어남), 개인정보 권한 부여/변경/삭제 기록은 5년 이상 저장하고 있는가.
- 3개월 이상 접속 기록이 없을 시 휴면 계정으로 전환하고 이 사실을 고지하는가.
- 개인정보 관련 추가 수집 시 추가 동의를 받고 있는가.
규모가 있는 회사는 정보보호팀이 별도로 존재하기 때문에 기획서 검토 의뢰를 통해 개인정보 영향 평가를 받고 거기서 나온 지적 사항들을 수정하여 적용하면 되지만 그렇지 않은 경우는 개인정보보호 종합 포털을 참고하시면 됩니다. 개인정보 보호 조치를 위해 필요한 모든 가이드를 제공해 주고 있으며 중소기업들을 위해 신청 시 위 역할을 대행해 주고 있습니다.
개인정보 영향 평가는 개발까지 완료된 상태에서 실시하면 수정 사항이 많이 나올 경우 큰 낭패가 될 수 있으므로 보통 기획 단계 또는 기획 완료 단계에서 챙기는 것이 바쁘더라도 나중에 더 수월합니다.
https://www.privacy.go.kr/main/mainView.do
개인정보 보안이 더욱 강화되고, 체계화되고 엄격해진 계기가 있었는데 국내 인터넷 역사에 남을 만한 대형 사고였지요. 바로 2011년 7월 26일 SK컴즈 개인정보 유출 사건으로 저도 그 현장에 있었습니다. 그 날은 Nate.com 메인 전면 개편이 있는 날이었고, 제가 맡은 서비스는 Miss A라는 걸그룹이 함께 하는 이벤트 오픈 건이 있어 보통 때보다 이른 출근을 했습니다. 당시 팀장은 파트장이던 저에게만 소식을 전하며, 팀원들에겐 알리지 말고 모든 작업을 중단하라고 지시했습니다. 유출 사고가 터지면 외부에(언론에) 알려지기 전에 방송통신위원회에 먼저 신고가 되어야 하기 때문이었는데, 새벽부터 출근한 수많은 직원들은 영문도 모른 채 손을 놓고 어리둥절해 하던 모습이 지금도 기억납니다.
그래서 개인정보 보호 관련된 컴플라이언스 준수의 중요성을 누구보다 체감하게 되었는데 많은 기획자, 개발자들에겐 좀 귀찮고, 불편하고, 왜 이렇게까지 해야 하는지 불만을 토로하기도 합니다. 불편해진 건 사실이며, 불편해진 몇 가지 것들을 예로 들어 보겠습니다.
- DRM(Digital Rights Management)이라는 허가된 사용자만 콘텐츠에 접근할 수 있도록 암호화하는 솔루션이 도입되어 모든 문서에 문서 보안이 걸려 있습니다. 이는 외부 유출 방지 및 문서의 불법 복제 방지 기능을 가지며, 필요시 문서 보안 해제 신청을 하고, 팀장 승인하에 해제가 가능합니다. 문서 보안이 걸려 있는 파일들은 개인 메일로 발송해도 외부에서 열 수가 없고, 파일 내용을 복사해 메일에 붙여 넣기도 할 수 없습니다.(하려면 해제 신청을 하거나 메일에 동일한 내용을 다시 입력해야 합니다)
- Google Suite, Dropbox, Trello, MS O365 등 모든 클라우드 서비스 이용을 통제합니다. 어떤 정보가 있는 사내 파일들이 클라우드 서비스들을 통해 유출되는지 알 수 없기 때문이지요. 그래서 일부 기업들은 CASB(Cloud Access Security Broker) 같은 보안 솔루션을 추가 도입하여 기업용 Google Suite or O365를 이용하는데 최소가 억대로 만만치 않은 비용입니다.
- 망분리(내부망과 외부망)에 따라 개발자들은 PC가 두대입니다. 개발은 외부망에 연결된 PC에서 하고, 내부망에 연결된 PC(인터넷이 안 되는)에서 운영 서버에 소스를 배포하는 등 기존보다 작업이 훨씬 번거롭고 귀찮아졌습니다.
- 개발 환경에서도 실제 운영 DB 일부를 가지고 테스트를 진행했으나 지금은 규정상 일체 금지되었으며 필요시 CISO(Chief Information Security Officer: 최고 정보보호 책임자)의 승인이 필요합니다.
- 제휴사나 벤더사에 제공하는 어드민에 로그인하기 위해서는 2 Factor 인증(아이디, 비밀번호로 로그인 후 폰 인증)을 해야 합니다.
- VPN(Virtual Private Network)이라는 가상 사설망 접속 후 사내망 시스템에 접근을 할 수 있는데 VPN에 접속하기 위해서는 OTP(One Time Password)를 사용하며, 인터넷 뱅크에서 계좌 이체 시 사용하는 그것 맞습니다.
- 내부망에서도 개인정보가 저장되어 있는 어드민에 접속하기 위해서는 VDI(Virtual Desktop Infrastructure)라는 가상 데스크톱에 접속 후 어드민에 로그인해야 하며, VDI 내에 있는 파일을 Local PC로 전송할 때 역시 승인이 필요합니다.
예전에는 본인이 작업한 파일들(기획 문서, 제안서, 디자인 산출물, 개발 소스 등)을 포트폴리오 차원에서 보관하기 위해 클라우드에 업로드하거나 개인 웹메일로 보냈는데 문서 보안 해제가 되어 있지 않는 이상 파일들은 열리지도 않고, 이렇게 외부 파일 전송은 원칙적으로 금지하고 있습니다. 또한 모니터링을 통해 개인정보가 포함된 파일을 유출한 경우 각각 소명을 요청하여 받고 있습니다.
위와 같은 보안 정책이 적용되어 있지 않은 곳들도 많이 있겠으나 ISMS(Information Security Management System)라는 정보통신망법 상 특정 요건에 해당하는 사업자가 의무적으로 받아야 하는 '정보보호 관리체계 인증'을 취득하기 위해서는 또는 취득한 기업들은 필수 요소들 중 일부입니다.
https://isms.kisa.or.kr/main/
보안 취약점 진단
일종의 모의 해킹 작업으로 이 역시 개인정보 유출 사고 이후 강화된 영역으로 신규 서비스를 비롯 모든 서비스가 해마다 점검을 받고, 진단 결과(항목별로 상/중/하로 나뉨)에 따른 조치를 해야 합니다. 예전에는 QA 과정에서 테스터들이 시도했던 일부 과정이었는데 이제는 보다 더 체계적이고 전문적인 분야로 자리를 잡았습니다.
신규 서비스는 취약점에 대한 조치를 완료해야지만 서비스 오픈을 할 수 있는데 긴급시 CISO의 승인 하에 오픈 후 처리가 가능하나 상 항목이 있는 경우는 보안에 너무 취약하여 오픈이 불가합니다.
사업팀 입장에서는 신규 기능이나 버그 수정이나 개선 사항 적용하기에도 빠듯한데 이 부분에 리소스를 투입해야 해서(이 조치로 수익이 좋아지거나 사용자가 더 늘어나는 요소는 아니므로) 그닥 달가운 부분이 아닐 것입니다.
그저 돌이킬 수 없는 SK컴즈 개인정보 유출 사고 같은 사태를 미연에 방지하는 차원이라 보시면 좋을 것 같습니다.
