3.2.1 개인정보 현황관리
인증기준: 수집·보유하는 개인정보의 항목, 보유량, 처리 목적 및 방법, 보유기간 등 현황을 정기적으로 관리하여야 하며, 공공기관의 경우 이를 법률에서 정한 관계기관의 장에게 등록하여야 한다.
결함사례#1
개인정보파일을 홈페이지의 개인정보파일 등록 메뉴를 통하여 목록을 관리하고 있으나, 그 중 일부 홈페이지 서비스와 관련된 개인정보파일의 내용이 개인정보 처리방침에 누락되어 있는 경우가 있다. 언제나 관리를 하건, 점검을 하건, 무엇을 하건, 일괄 적용을 원칙으로 삼아야 한다. 시간 상의 문제건, 인력 상의 문제건 누락을 하는 것은 있어서는 안 될 일로 여겨야 한다. 내가 ISMS-P 업무를 맡던 도중 이를 위해 야근을 해야 한다면 어쩔 수 없이 해야 한다는 사실을 받아들일 것 같다. 차라리 전부 안해서 결함사례로 판정되는 것도 아니고, 일부가 누락되어서 판정되는 것은 너무 억울한 일이 될테니 말이다.
결함사례#2
신규 개인정보파일을 구축한 지 2개월이 경과하였으나, 해당 개인정보파일을 개인정보 보호위원회에 등록하지 않은 경우가 있다. 법령 상 개인정보파일에 관해서는 적정성을 검토한 후 60일이라는 넉넉한 시간 이내에 등록을 하여야 한다. 32조 2항을 제외한 모든 경우가 해당되니 이에 대해서는 변명의 여지가 없을 것이다.
결함사례#3
개인정보 보호위원회에 등록되어 공개된 개인정보파일의 내용(수집하는 개인정보의 항목 등)이 실제 처리하고 있는 개인정보파일 현황과 상이한 경우가 있다. 이는 현황 관리가 제대로 이뤄지지 않았다는 것을 의미한다. 변동이 생길 때마다 이에 대한 업무를 미루지 말고 처리하는 것을 기본으로 삼아야 할 것이다.
결함사례#4
공공기관이 임직원의 개인정보파일, 통계법에 따라 수집되는 개인정보파일에 대해 개인정보파일 등록 예외사항에 해당되지 않음에도 불구하고 해당 개인정보파일을 개인정보 보호위원회에 등록하지 않은 경우가 있다. 에외사항에 해당되는 것이 많기야 하다. 그래서 해석에 관한 문제가 생긴다면야 개인정보 보호위원회에 문의를 하면 될 일이다. 60일이라는 시간 내에 그것을 확인하기는 너무도 충분하지 않을까 싶다.
3.2.2 개인정보 품질보장
인증기준: 수집된 개인정보는 처리 목적에 필요한 범위에서 개인정보의 정확성·완전성·최신성이 보장되도록 정보주체에게 관리절차를 제공하여야 한다.
결함사례#1
인터넷 홈페이지를 통하여 회원정보를 변경할 때는 본인확인 절차를 거치고 있으나, 고객센터 상담원과의 통화를 통한 회원 정보 변경 시에는 본인확인 절차가 미흡하여 회원정보의 불법적인 변경이 가능한 경우가 있다. 여태까지 정말 많은 고객센터와 통화를 했는데, 매번 방식은 비슷했다. 성명을 대면서 본인인지 확인을 하고, ASR 단계에서 주민등록번호 입력을 통해 추가적인 인증을 하는 것이다. 아마 이 부분은 대한민국 성인이라면 대다수 공감하는 내용이지 않을까 싶다. 사회적으로 대부분의 회사와 조직에서 차용하는 시스템이 존재하는데 이에 대해 절차가 미흡하다는 것은 정말 해당 내용에 대해 관심이 없다는 것으로 보인다. 물론 성명+핸드폰 번호+주민등록번호 인증은 가족 구성원이 대신 하는 것이 쉽기야 하다만, 법에서 할 수 있는 최선의 내용을 다하는 것을 소명으로 삼아야 할 것이다.
결함사례#2
온라인 회원에 대해서는 개인정보를 변경할 수 있는 방법을 제공하고 있으나, 오프라인 회원에 대해서는 개인정보를 변경할 수 있는 방법을 제공하고 있지 않은 경우가 있다. 온라인과 오프라인에 대해서 차별을 두어서는 아니 된다. 정확히는 정보주체에게 자신의 개인정보에 관한 정확성, 완전성, 최신성을 유지할 수 있는 방법을 반드시 반드시 반드시 제공하여야 하기 때문에 이 과정에 있어서 일부는 되고, 일부는 안 되는 상황은 있어서는 안 되는 일이다. 특히나 공단에서 일을 하면서 느낀 것이 있는데, 노년의 어르신들의 경우 오프라인을 통한 업무를 매우 선호하신다는 점이다. 온라인 자체에 대한 거부감이 있으셔서 그러신 느낌이었다. 그렇기에 오프라인에 차별을 두는 것은 노년에 대한 차별로 이어질 수 있다. 물론 중요하지 않은 사람이야 있겠냐만은, 개인적으로 노년층에 대한 배려는 정보화가 가속되는 사회에서는 절대 빼서는 안 될 요소라고 느낀다.
3.2.3 이용자 단말기 접근 보호
인증기준: 정보주체(이용자)의 이동통신단말장치 내에 저장되어 있는 정보 및 이동통신단말장치에 설치된 기능에 접근이 필요한 경우 이를 명확하게 인지할 수 있도록 알리고 정보주체 (이용자)의 동의를 받아야 한다.
결함사례#1
스마트폰 앱에서 서비스에 불필요함에도 불구하고 주소록, 사진, 문자 등 스마트폰 내 개인정보 영역에 접근할 수 있는 권한을 과도하게 설정한 경우가 있다. 권한에 대해서는 언제나 서비스의 기능을 수행하기 위한 최소한의 권한만을 설정해야 한다. 어디서나 권한에 있어서 '최소한의 원칙'은 통용되는 것이지 않을까 싶다. 보통 이용자들이 이런 권한 동의에 있어서 제대로 확인하고 동의하는 경우가 많지 않을 것이다. 젊은 사람도 그런데, 어린 아이나 노년의 경우는 더욱 그럴 테고 말이다. 그렇기에 특히나 이에 대해 법에서 엄격하게 통제할 필요가 있을 것으로 보인다. 해당 애플리케이션에서 '동의를 받았는데요?'라는 식으로 나온다면 이로 인한 피해가 극심해질 것이니 말이다.
결함사례#2
정보통신서비스 제공자의 스마트폰 앱에서 스마트폰 내에 저장되어 있는 정보 및 설치된 기능에 접근하면서 접근권한에 대한 고지 및 동의를 받지 않고 있는 경우가 있다. 과도한 접근권한을 넘어서서 이제는 아예 동의받지도 않은 접근권한을 행사한다니.. 이건 정말 국가에서 고위험군 앱으로 선정하여 당장 해당 회사에 대해 제재를 가해도 할 말이 없지 않을까 싶다. 개인적으로 동의를 구하지도 않는다는 것은 해킹, 개인정보 유출 외에는 그 어떠한 이유나 핑계를 댈 수 없다고 생각한다.
결함사례#3
스마트폰 앱의 접근권한에 대한 동의를 받으면서 선택사항에 해당하는 권한을 필수권한으로 고지하여 동의를 받는 경우가 있다. 필수사항과 선택사항에 대한 구분은 분명히 해야 하며, 이용자가 이를 쉽게 식별할 수 있게 만들어야 한다. 개인적으로는 필수사항과 선택사항 사이에 다소 공란을 두는 것도 이용자를 위한 일이라고 생각한다. 그래서 이 식별에 관한 법적 내용이 조금 더 세부적으로 성문화되어 강화되었으면 하는 바람이 있다.
결함사례#4
접근권한에 대한 개별동의가 불가능한 안드로이드 6.0 미만 버전을 지원하는 스마트폰 앱을 배포하면서 선택적 접근권한을 함께 설정하여, 선택적 접근권한에 대하여 거부할 수 없도록 하고 있는 경우가 있다. 이것도 결국은 선택사항을 강제하는 일이 될 것이다. 특히나 어르신들의 경우 안드로이드 6.0 미만의 버전을 사용하는 경우가 종종 있을 텐데, 솔직히 그분들을 대상으로 사기를 치는 일이지 않나 하는 의심이 강하게 든다. 본인들의 영리적 목적을 달성하기 위한 용도로 말이다. 이런 권한을 제멋대로 요구하는 일에 있어서는 더욱 처벌이 강화되길 바라는 마음이 있다.
3.2.4 개인정보 목적 외 이용 및 제공
인증기준: 개인정보는 수집 시의 정보주체에게 고지·동의를 받은 목적 또는 법령에 근거한 범위 내에서만 이용 또는 제공하여야 하며, 이를 초과하여 이용·제공하려는 때에는 정보주체의 추가 동의를 받거나 관계 법령에 따른 적법한 경우인지 확인하고 적절한 보호대책을 수립·이행하여야 한다.
결함사례#1
상품배송을 목적으로 수집한 개인정보를 사전에 동의 받지 않은 자사 상품의 통신판매 광고에 이용한 경우가 있다. 목적 외 이용 및 제공이 가능한 경우에 대해 법적 내용을 굳이 검토할 필요도 없다. 지나가는 사람에게 제멋대로 주먹질을 한 사람에게 법적 내용을 굳이 검토해 가며 고쳐야 할 행동에 대해 말해 줄 필요가 없는 것처럼 말이다. 이런 기업에 대해서는 정말이지 소비자의 알권리가 적용되어야 하지 않을까 싶다.
결함사례#2
고객 만족도 조사, 경품 행사에 응모하기 위하여 수집한 개인정보를 자사의 할인판매행사 안내용 광고 발송에 이용한 경우가 있다. 이것도 결국 #1과 크게 다를 바 없다. #1이 중범죄라면, #2는 경범죄인 느낌의 죄질 차이랄까. 그러나 중범죄나 경범죄나 결국엔 범법행위인 건 매한가지이다. 이런 얌체짓을 일삼는 기업에 대해서는 분명한 조치를 취하면 좋겠다.
결함사례#3
공공기관이 다른 법률에 근거하여 민원인의 개인정보를 목적 외로 타 기관에 제공하면서 관련 사항을 관보 또는 인터넷 홈페이지에 게시하지 않은 경우가 있다. 목적 외로 사용할 법적 근거가 충분하다 한들, 이에 대해 통보를 하는 것은 당연히 이뤄져야 한다. 물론 예외 사항이 있기는 하다만, 예외 사항이 몇 되지도 않고, 굳이 해석이 필요하지도 않을 정도로 내용이 분명한 만큼 이에 대해서는 공공기관의 명백한 잘못으로 봐야 할 것이다.
결함사례#4
공공기관이 범죄 수사의 목적으로 경찰서에 개인정보를 제공하면서 ʻ개인정보 목적 외 이용 및 제3자 제공 대장ʼ에 관련 사항을 기록하지 않은 경우가 있다. 언제나 제공이 합당하며, 법적 근거로 인한 것이라 한들, 그것에 대한 절차는 분명하게 기록하여야 한다. 이것 역시 법으로 강제되어 있으며, 무엇을 기록해야 하는지 친절하게 알려주고 있기 때문에 결코 어려운 일이 아닐 것이다.
3.2.5 가명정보 처리
인증기준: 가명정보를 처리하는 경우 목적제한, 결합제한, 안전조치, 금지의무 등 법적 요건을 준수하고 적정 수준의 가명처리를 보장할 수 있도록 가명처리 절차를 수립·이행하여야 한다.
결함사례#1
통계작성 및 과학적 연구를 위하여 정보주체 동의 없이 가명정보를 처리하면서 가명정보 처리에 관한 기록을 남기고 있지 않거나, 또는 개인정보 처리방침에 관련 사항을 공개하지 않은 경우가 있다. 공부할 때 '통과공'으로 외웠던 기억이 문득 난다. 통계적 목적, 과학적 연구 목적, 공익적 기록 보존의 경우라 하더라도 기록을 남기는 것은 필수로 여겨야 한다. 동의 없이 처리가 가능하다는 것 뿐이지, 기록도 남기지 않아도 된다는 것은 아니니 말이다. 언제나 변동이 생길 경우의 기록은 필수다.
결함사례#2
가명정보와 동일한 데이터베이스 내에 추가 정보를 분리하지 않고 보관하고 있거나, 또는 가명 정보와 추가 정보에 대한 접근권한이 적절히 분리되지 않은 경우가 있다. 이에 대해 분리를 하지 않으면 문제가 생길 여지가 있다. 이는 법을 차치하더라도 안전성 확보를 위한 최소한의 조치로 여겨야 하며, 가명정보 및 추가정보를 안전하게 관리 위한 내부 관리계획의 수립 및 이행이 필요하다.
결함사례#3
개인정보를 가명처리하여 활용하고 있으나 적정한 수준의 가명처리가 수행되지 않아 추가 정보의 사용 없이도 다른 정보와의 결합 등을 통하여 특정 개인을 알아볼 수 있는 가능성이 존재하는 경우가 있다. 이런 경우 Aggregation나 Inference 공격 등에 쓰일 소지가 다분하다. 과거 공공기관에서 이런 방식으로 피해자의 신상 정보를 확보하여 범죄에 사용한 사례가 간혹 있었다. 따라서 이에 대해 가능성을 차단할 수 있는 방안을 도입해야 한다. 이는 실제 범죄 사례가 있었기에 더욱 중요시 여겨야 한다.
결함사례#4
테스트 데이터 생성, 외부 공개 등을 위하여 개인정보를 익명처리하였으나, 특이치 등으로 인하여 특정 개인에 대한 식별가능성이 존재하는 등 익명처리가 적정하게 수행되었다고 보기 어려운 경우가 있다. 가명처리, 익명처리를 할 때는 언제나 그 적정성을 검토하는 과정이 필요하다. 그것을 수행하지 않았다면 제대로 처리를 하였다고 보기 어려울 것이다. 익명처리 과정에서 단순 개인정보가 아닌 개인식별정보가 삭제되어야 한다. 그후에 적정성 검토를 위한 절차를 밟아야 하는 것이다. 이런 경우에는 적정성 검토가 사실상 이뤄지지 않았다고 봐야 할 것이다.
'보안 > 개념' 카테고리의 다른 글
ISMS-P 결함사례 고찰 #3.4. 개인정보 파기 시 보호조치 (1) | 2024.01.15 |
---|---|
ISMS-P 결함사례 고찰 #3.3. 개인정보 제공 시 보호조치 (1) | 2024.01.15 |
ISMS-P 결함사례 고찰 #3.1. 개인정보 수집 시 보호조치 (1) | 2024.01.13 |
ISMS-P 결함사례 고찰 #2.12. 재해 복구 (0) | 2024.01.12 |
ISMS-P 결함사례 고찰 #2.11. 사고 예방 및 대응 (1) | 2024.01.12 |