ISMS-P 결함사례 고찰 #2.5. 인증 및 권한관리

2.5.1 사용자 계정 관리

인증기준: 정보시스템과 개인정보 및 중요정보에 대한 비인가 접근을 통제하고 업무 목적에 따른 접근권한을 최소한으로 부여할 수 있도록 사용자 등록·해지 및 접근권한 부여·변경·말소 절차를 수립·이행하고, 사용자 등록 및 권한부여 시 사용자에게 보안책임이 있음을 규정화하고 인식시켜야 한다.

 

결함사례#1

사용자 및 개인정보취급자에 대한 계정·권한에 대한 사용자 등록, 해지 및 승인절차 없이 구두 요청, 이메일 등으로 처리하여 이에 대한 승인 및 처리 이력이 확인되지 않는 경우가 있다. 절차 없이 구두나 이메일로만 처리하게 되면 이에 대한 책임 권한을 따지는 것이 불분명해지게 된다. 결국 책임은 해당 사용자 보다는 담당자가 지게 되는 것이다. 명확한 절차를 거쳐서 해당 계정에 대한 보안책임이 주어진다는 것을 명확하게 이해시켜야 할 것이다.

 

결함사례#2

개인정보취급자가 휴가, 출장, 공가 등에 따른 업무 백업을 사유로 공식적인 절차를 거치지 않고 개인정보취급자로 지정되지 않은 인원에게 개인정보취급자 계정을 알려주는 경우가 있다. 공식적인 절차를 거치게 되면 조직 사정에 따라 수일까지 걸릴 수도 있을 것이다. 당장 업무는 투입되어서 해야할 일이 있는데, 절차를 기다리다가는 일을 할 수가 없게 되니 그냥 계정을 알려주고 마는 것이다. 이에 대해서 평소 정/부 시스템을 도입하는 것도 괜찮을 것이다. 그래서 미리 개인정보취급에 관한 권한을 받을 수 있게 하는 것이다. 그리고 보안부서는 이런 사항을 일반 직원들에게 알려야 한다. 

 

결함사례#3

정보시스템 또는 개인정보처리시스템 사용자에게 필요 이상의 과도한 권한을 부여하여 업무상 불필요한 정보 또는 개인정보에 접근이 가능한 경우가 있다. 각 사용자마다 최소권한의 원칙을 지켜야 하는데, 귀찮으니까 무분별하게 허가를 준 것이다. 해당 사용자가 속한 부서에서 보안부서에 그냥 그 부서의 총괄적인 권한을 요구했을 가능성도 있다. a팀에 속한 a1의 업무를 맡은 직원이 있는데, 그 직원이 a2를 맡게될 경우도 있으니, 그냥 a전체의 권한을 달라고 요구하는 사례인 것이다. 보안부서는 언제나 해당 직원의 직무기술서에 따른 최소권한만을 부여하는 것을 원칙으로 삼아야 할 것이다.

 

2.5.2 사용자 식별

인증기준: 사용자 계정은 사용자별로 유일하게 구분할 수 있도록 식별자를 할당하고 추측 가능한 식별자 사용을 제한하여야 하며, 동일한 식별자를 공유하여 사용하는 경우 그 사유와 타당성을 검토하여 책임자의 승인 및 책임추적성 확보 등 보완대책을 수립·이행하여야 한다.

 

결함사례#1

정보시스템(서버, 네트워크, 침입차단시스템, DBMS 등)의 계정 현황을 확인한 결과, 제조사에서 제공하는 기본 관리자 계정을 기술적으로 변경 가능함에도 불구하고 변경하지 않고 사용하고 있는 경우가 있다. 보통은 기술적으로 변경이 불가능한 경우가 아주 적을 것이다. 이것이 문제가 될 것이라고 생각하지 않고 이렇게 하는 건데, 기본 관리자 계정을 바꾸는 것은 당연한 수순이며, 굳이 유지해야 한다면 그에 따른 타당한 이유를 댈 수 있어야 할 것이다.

 

결함사례#2

개발자가 개인정보처리시스템 계정을 공용으로 사용하고 있으나, 타당성 검토 또는 책임자의 승인 등이 없이 사용하고 있는 경우가 있다. 이렇게 계정을 공용으로 사용하는 것도 매우 흔한 일 중 하나다. 그리고 이것은 분명한 문제가 된다. 공용계정을 사용해야 하는 경우에는 그 사유와 타당성이 있어야만 한다. 공용계정의 문제 중 하나가 바로 책임추적성에 대한 보장이 되지 않는다는 것인데, 사용이 불가피한 경우에는 이에 대한 대안을 마련해야 할 것이다.

 

결함사례#3

외부직원이 유지보수하고 있는 정보시스템의 운영계정을 별도의 승인 절차 없이 개인 계정처럼 사용하고 있는 경우가 있다. 언제나 1인 1계정은 원칙으로 여겨야 한다. 그것이 외부직원이라 하더라도 말이다. 외부직원에 대한 권한을 철저히 관리하고, 권한 관리 및 회수에 대해서도 주의를 기울여야 할 것이다.

 

2.5.3 사용자 인증

인증기준: 정보시스템과 개인정보 및 중요정보에 대한 사용자의 접근은 안전한 인증절차와 필요에 따라 강화된 인증방식을 적용하여야 한다. 또한 로그인 횟수 제한, 불법 로그인 시도 경고 등 비인가자 접근 통제방안을 수립·이행하여야 한다.

 

결함사례#1

개인정보취급자가 공개된 외부 인터넷망을 통하여 이용자의 개인정보를 처리하는 개인정보처리 시스템에 접근 시 안전한 인증수단을 적용하지 않고 ID·비밀번호 방식으로만 인증하고 있는 경우가 있다. ID, PW 방식은 가장 약한 인증방식이라고 말할 수 있으며, 다양한 인증수단을 도입하는 것이 좋다. 만약 예산 상 문제로 인증수단 도입에 다소 시일이 걸린다고 하면, 비밀번호의 길이와 난이도를 올려서 조금이라도 보안성을 확보하는 것이 좋다고 생각한다. 설령 편의성을 위해 SSO를 도입하고자 할 때도 강화된 인증수단을 이용해야 할 것이다.

 

결함사례#2

정보시스템 및 개인정보처리시스템 로그인 실패 시 해당 ID가 존재하지 않거나 비밀번호가 틀림을 자세히 표시해 주고 있으며, 로그인 실패횟수에 대한 제한이 없는 경우가 있다. 이 정도면 거의 계정 좀 뚫어주세요 라고 하는 정도가 아닐까 싶다. 로그인 실패횟수 같은 경우는 개인정보의 안전성 확보조치에 기술되어 있는 내용이고, 틀림을 자세히 표시해 주는 것은 명시되어 있지는 않기는 하더라도 솔직히 생각해 본 적도 없는 문구다. 틀렸으면 틀렸다고만 알리면 되지, 아이디가 잘못 입력되었는지, 패스워드가 잘못 입력되었는지를 알려줄 이유가 없다는 것이다. 여하튼 인증수단을 이용할 때는 언제나 편의성 보다는 공격자 입장에서 생각하는 것이 좋다.

 

2.5.4 비밀번호 관리

인증기준: 법적 요구사항, 외부 위협요인 등을 고려하여 정보시스템 사용자 및 고객, 회원 등 정보주체 (이용자)가 사용하는 비밀번호 관리절차를 수립·이행하여야 한다.

 

결함사례#1

정보보호 및 개인정보보호 관련 정책, 지침 등에서 비밀번호 생성규칙의 기준을 정하고 있으나, 일부 정보시스템 및 개인정보처리시스템에서 내부 지침과 상이한 비밀번호를 사용하고 있는 경우가 있다. 모든 시스템에서는 지침에 의거한 룰을 적용하도록 해야 한다. 이것은 초창기에만 적용을 일괄적으로 하면 되는데 누락되었다는 것을 사실 이해하기 힘들다.

 

결함사례#2

비밀번호 관련 내부 규정에는 비밀번호를 초기화 시 임시 비밀번호를 부여받고 강제적으로 변경하도록 되어 있으나, 실제로는 임시 비밀번호를 그대로 사용하고 있는 경우가 있다. 임시 비밀번호는 비밀번호를 바꿀 때 사용해본 사람은 알겠지만, 전혀 의미하는 바가 없이 복잡하게 나열되어 있는 것이 보통이다. d^k139ehkf@dw29! 같은 식으로 말이다. 그리고 이것을 그대로 사용한다는 것은 장담하는데 어딘가 메모장 혹은 스티커 따위에 그대로 기재했을 가능성이 크다. 정말 이것은 내가 확신할 수 있다. 일반적인 사람이 저런 의미없는 나열을 외우고 다닐 가능성이 없기 때문이다. 따라서 임시 비밀번호를 쓰는 사용자에 대해서는 조치를 취해야만 한다.

 

결함사례#3

비밀번호 관련 내부 규정에는 사용자 및 개인정보취급자의 비밀번호 변경주기를 정하고 이행하도록 하고 있음에도 불구하고 변경하지 않고 그대로 사용하고 있는 경우가 있다. 이것은 강제해야 한다. 그런데 강제하되, 똑같은 비밀번호로 바꾸게 하지는 못하게 해야 한다. 비밀번호가 1q2w3e4r%^이라고 할 때, 이것을 무슨 제자리걸음 하는 것처럼 1q2w3e4r%^로 바꾸는 것을 막아야 한다는 것이다. 물론 사용자가 비밀번호 변경을 2번 해서 다시 원 비밀번호로 바꾼다거나, 기껏해야 1q2w3e4r%^에서 1q2w3e4r!@로 바꾸는 것은 막을 수 없겠다만, 규정에 의거한 의무를 다해야 한다는 것이다.

 

2.5.5 특수 계정 및 권한 관리

인증기준: 정보시스템 관리, 개인정보 및 중요정보 관리 등 특수 목적을 위하여 사용하는 계정 및 권한은 최소한으로 부여하고 별도로 식별하여 통제하여야 한다.

 

결함사례#1

정보시스템 및 개인정보처리시스템의 관리자 및 특수권한 부여 등의 승인 이력이 시스템이나 문서상으로 확인이 되지 않거나, 승인 이력과 특수권한 내역이 서로 일치되지 않는 경우가 있다. 담당자는 주기적으로 현황을 점검하여 문서상 권한과 실제 권한이 일치하는지, 그 권한의 타당성은 여전한지에 대해 검증할 필요가 있다. 반드시 이것은 주기적으로 실행해야 하는 업무로 여겨야 한다.

 

결함사례#2

내부 규정에는 개인정보 관리자 및 특수권한 보유자를 목록으로 작성·관리하도록 되어 있으나 이를 작성·관리하고 있지 않거나, 보안시스템 관리자 등 일부 특수권한이 식별·관리되지 않는 경우가 있다. 특수 계정은 특히나 일반 계정과는 구분되는 개념이다. 공식적인 절차에 의거하여 수립 및 이행되는 것이 특수계정인 만큼, 이에 대한 관리를 별도로 실시해야 한다.

 

결함사례#3

정보시스템 및 개인정보처리시스템의 유지보수를 위하여 분기 1회에 방문하는 유지보수용 특수 계정이 사용기간 제한없이 상시로 활성화되어 있는 경우가 있다. 사용기간을 제한하는 것은 기술적으로 결코 어려운 일이 아니다. 유지보수용 특수 계정을 사용하는 시기가 언제인지 스케줄을 제대로 체크하고, 이에 대해 사용기한을 분명하게 설정해야 할 것이다.

 

결함사례#4

관리자 및 특수권한의 사용 여부를 정기적으로 검토하지 않아 일부 특수권한자의 업무가 변경되었음에도 불구하고 기존 관리자 및 특수권한을 계속 보유하고 있는 경우가 있다. 이것은 최소권한의 원칙에 위배되는 것으로, 특수계정도 일반계정과 마찬가지로 변동이 생길 경우 즉시 해당 내용을 반영해야 할 것이다.

 

2.5.6 접근권한 검토

인증기준: 정보시스템과 개인정보 및 중요정보에 접근하는 사용자 계정의 등록·이용·삭제 및 접근권한의 부여·변경·삭제 이력을 남기고 주기적으로 검토하여 적정성 여부를 점검하여야 한다.

 

결함사례#1

접근권한 검토와 관련된 방법, 점검주기, 보고체계, 오·남용 기준 등이 관련 지침에 구체적으로 정의되어 있지 않아 접근권한 검토가 정기적으로 수행되지 않은 경우가 있다. 구체적으로 정의하는 것을 귀찮게 여기는 사람들이 있는데, 개인적으로는 오히려 구체적으로 기술하는 것이 업무에 있어서는 훨씬 수월하다고 생각한다. 무엇이는 절차화, 지침화, 규정화하는 것은 일종의 체크리스트를 만들 수 있고, 그것이 업무에서 무언가 누락되지 않도록 만들어주기 때문이다. 특히 보안 분야에서 자신이 어떠한 업무를 맡건, 정기적 검토라는 개념은 항상 있어야 한다는 점을 분명히 인지해야 할 것이다.

 

결함사례#2

내부 정책, 지침 등에 장기 미사용자 계정에 대한 잠금(비활성화) 또는 삭제 조치하도록 되어 있으나, 6개월 이상 미접속한 사용자의 계정이 활성화되어 있는 경우(접근권한 검토가 충실히 수행되지 않아 해당 계정이 식별되지 않은 경우)가 있다. 이것도 기술적으로 장기간 미사용 계정 잠금을 하는 것이 결코 어려운 일이 아니다. 지침에 의거하여 이에 대해서도 조치를 취해야 할 것이다.

 

결함사례#3

접근권한 검토 시 접근권한의 과다 부여 및 오·남용 의심사례가 발견되었으나, 이에 대한 상세조사, 내부보고 등의 후속조치가 수행되지 않은 경우가 있다. 으레 그렇게 하니까 조사를 하지 않는 경우가 되겠다. 특히 아래에 있는 직원일 경우 이것에 대해 조치를 수행하기는 어려울 것이다. 그러나 이에 대한 보고서를 만들어 놓는 것은 필수적이다. 실제로 조치를 수행하기에는 현실적으로 어렵다고 하더라도, 이에 대한 경고를 꾸준히 해야만 할 것이다. 그게 최소한의 책임을 다하는 일이라고 생각한다.