태그검색
찾고 싶은 것이 있나요?
보안에 대한 207개의 태그 검색결과가 있습니다.
- 블로그 [보안동향] 잊지 마세요! 개인정보 수집보다 중요한 ‘OO’ 2편 지난 글에서는 개인정보 파기 관련 법령과 개인정보 파기 시점에 관해 알아보았습니다. 이번 글에서는 개인정보 삭제 방법과 개인정보 분리∙보관을 함께 살펴보겠습니다. 5. 개인정보 삭제 방법 개인정보를 파기할 때는 개인정보보호법 제21조 2항에 의거해 복구 또는 재생되지 않도록 조치해야 하는데요. 이에 대한 구체적인 방법으로 4항에 의거한 시행령과 행정규칙을 알아보겠습니다. 개인정보 수집은 서면, 우편, 통화 등 다양한 방법으로 이뤄집니다. 그렇기 때문에 파기 대상도 이에 따라 종이 문서, 전자우편, 음성녹음 파일, 전자문서, 데이터베이스 등으로 다양하죠. 데이터베이스에 저장된 데이터뿐만 아니라 각종 매체에 존재하는 개인정보도 파기 대상이 되는데요. 이때 매체별로 보존기간이 다를 수 있고, 파기 방법도 달라질 수 있습니다. 앞서 언급한 대로, 개인정보의 파기는 기본적으로 재생과 복구가 불가능한 방법으로 파기해야 하는데요. ‘복원이 불가능한 방법’이란 사회 통념상 적정한 비용을 통해 개인정보의 복원이 불가능하도록 파기하는 조치 방법을 말합니다. 개인정보의 안전성 확보 조치 기준 해설서에 따르면, 개인정보 파기 전문 업체를 활용할 수 있습니다. 다만 개인정보 파기의 시행 및 파기 결과의 확인은 개인정보보호 책임자의 책임하에 수행돼야 하고, 파기에 관한 사항을 기록∙관리해야 합니다. 6. 정보통신서비스의 장기 미사용 이용자 보호를 위한 파기 다음은 정보통신서비스 이용자 중 장기 미사용 시 파기 또는 분리∙보관에 대한 특례 조항을 살펴보겠습니다. 정보통신서비스 제공자는 서비스를 1년 또는 이용자의 요청으로 정한 특정 기간 이상 미사용한 이용자의 개인정보에 대해 파기 등 보호 조치를 취해야 합니다. 파기의 경우 미사용 기간 만료 30일 전 ‘개인정보가 파기되는 사실, 기간 만료일 및 파기되는 개인정보의 항목’을 이용자에게 통지하고, 마지막 사용 후 미사용 기간이 만료되면 개인정보를 파기 조치합니다. 통신비밀보호법시행령, 의료법, 근로기준법 등 다른 법령에 따라 이용자의 개인정보를 분리∙보관하는 경우에는 미사용 기간 만료 30일 전 ‘개인정보가 분리돼 저장∙관리되는 사실, 기간 만료일 및 분리∙저장돼 관리되는 개인정보의 항목’을 이용자에게 통보해야 합니다.이후 미사용 기간이 도래하면 다른 법령에서 정한 보존기간이 경과할 때까지 다른 이용자의 개인정보와 분리해 별도로 저장∙관리해야 합니다. 정보 생명주기 관리 솔루션을 사용해 거래 종료된 고객의 개인신용정보를 파기 데이터 보관 시스템으로 구축할 수 있는데요. 이를 통해 인가된 관리자, 승인된 사용자만 접근하도록 제한할 수 있습니다. 주의할 점은 분리∙보관하는 개인정보는 해당 법령에서 규정하는 경우를 제외하고는 개인정보를 이용하거나 제공하지 않아야 한다는 점입니다. 7. 법령에 따른 파기 대상 개인정보의 분리보관 개인정보보호법 제21조 3항에서는 보존 대상 개인정보를 분리∙보관할 것을 명시하고 있습니다.보관기간은 해당 사업 영역에 적용되는 관련 법령에서 정의하고 있는 보존 기한을 따르는데요. 법령에서 정한 보유 기간에는 파기 대상 개인정보를 원본에서 분리해 보관해야 합니다. 그렇지 않으면 파기 대상 정보 주체가 전체 개인정보를 대상으로 하는 메일 발송에 포함되는 등 정보 주체의 권리 침해가 발생할 수 있기 때문입니다. 아래는 보존기간을 정의하고 있는 법령의 예시입니다. 개인정보 분리는 별도의 데이터베이스나 저장매체에 할 수 있습니다. 같은 테이블 스페이스 내 별도 테이블에 저장하는 논리적 분리도 가능하죠. 데이터 저장 단위 중 가장 상위에 있는 단위를 테이블 스페이스라고 합니다. 다만, 원본과 동일한 접근권한을 가지고 동일 애플리케이션을 통해 접근하는 것은 허용하지 않는데요. 분리보관 대상 정보에 대해서는 별도의 권한으로 접근 통제가 이뤄져야 합니다. 대량의 개인정보를 다룰 경우, 파기 대상 개인정보를 별도 디스크로 옮겨주는 솔루션을 이용할 수 있습니다. 솔루션은 애플리케이션에서 운영 스토리지와 아카이빙 스토리지로 분리 저장하는 S/W 방식, 운영 스토리지에 저장된 정보를 아카이빙 스토리지로 옮겨주는 H/W 방식이 있습니다. 아카이빙 스토리지는 고객사에서 생성되고 있는 비즈니스 문서, 이메일, 콘텐츠 등과 같이 한번 생성이 되면 변경되지 않는 고정 콘텐츠를 장기간 위변조 없이 안정적으로 보관할 수 있는 스토리지라고 정의할 수 있습니다. 8. 분리보관 개인정보의 삭제 관련 법령에 의해 개인정보를 분리·보관할 때도 보유 기간을 지켜야 합니다.분리보관 데이터는 영구 보관 대상이 아니며, 법령에 명시된 기간이 경과하면 차례대로 파기하도록 구현해야 합니다. 개인정보를 사용할 때는 수집∙저장∙이용∙제공뿐만 아니라 파기까지 관리해야 완전하게 라이프 사이클상에서의 보호조치를 다 했다고 할 수 있습니다.지금까지 개인정보 처리자가 소홀히 다루기 쉬운 개인정보의 파기에 대해 알아보았습니다. 글 ㅣ LG CNS 사이버시큐리티팀 권영미 책임
- 블로그 [보안동향] 잊지 마세요! 개인정보 수집보다 중요한 ‘OO’ 1편 개인정보를 이용∙제공하기 위해 이를 수집하고 저장하는 시스템이 바로 ‘개인정보처리시스템’입니다. 개인정보는 수집/저장/이용/제공돼 파기에 이르기까지 일정한 라이프사이클을 따라 흐르게 되는데요. 정보주체의 동의를 받아서 개인정보를 안전하게 저장하고 이용하는 것도 중요하지만, 이에 못지않게 잘 파기하는 것 역시 중요합니다. 적법하게 수집한 정보라도 정보의 이용 기한이 만료되면 즉시 삭제해야 하죠. 개인정보는 관련 법령에 따라 필요시 분리보관의 대상이 되기도 합니다. 개인정보 파기 기능을 구현하지 않고 시스템을 운영하는 경우도 종종 있습니다. 개인정보 파기 기능이란 보유기간의 경과, 개인정보의 처리 목적 달성 등 개인정보가 불필요하게 되었을 때 지체없이 개인정보를 파기하는 기능을 의미합니다. 오래된 시스템에서 그동안 개인정보를 삭제하지 않고 사용하는 경우나, 아직 삭제 주기가 도래하지 않았다는 이유로 새로운 시스템에 파기 기능을 구현하지 않고 운영해온 경우입니다. 하지만, 개인정보 파기 기능을 시스템으로 구현해 놓지 않으면, 삭제 주기가 도래한 후에 운영자가 해당 개인정보의 저장소를 확인하고 대상을 선별해 일일이 삭제 처리해야 합니다. 이때, 잘못된 판단으로 일부 개인정보가 파기에서 누락되는 일이 발생할 수도 있죠. 그러므로 시스템 설계부터 이를 고려해 구축하는 것이 바람직합니다. 개인정보의 보유기간과 같은 파기 정책이 없을 수도 있는데요. 파기해야 하는 정보를 잘 모르거나, 올바른 파기 방법을 모르는 경우에도 개인정보 파기에 어려움을 겪을 수 있습니다. 파기 대상이 되는 개인정보가 무엇인지부터 개인정보 분리보관에 대한 법적 근거와 함께 조치 방법까지, 개인정보 파기에 필요한 요소를 살펴보겠습니다. 1. 파기 대상 개인정보 개인정보처리시스템에서 수집∙저장∙이용하는 개인정보는 주로 서비스를 이용하기 위해 가입한 회원이나 외부 고객의 정보입니다. 하지만 그 외에도 내부 시스템에서 업무를 처리하기 위해 등록된 사용자로 관리자, 운영자, 협력업체 또는 외부 거래처 담당자의 개인정보가 포함될 수 있는데요. 빠뜨리기 쉬운 개인정보가 바로 이런 정보입니다. 개인정보의 유형으로는 사번(시스템 키), 성명 외에 이메일, 전화번호와 같은 연락처가 있습니다. 개인정보는 시스템에 저장된 정보 외에도 수집경로에 따라 종이 문서, 우편, 전자메일, 팩스, 전자문서, 통화 녹음 파일, 사진이나 영상 파일 등 다양한 형식으로 존재할 수 있습니다. 이렇게 데이터베이스에 저장된 데이터뿐만 아니라 각종 매체에 존재하는 개인정보도 파기 대상이 되는데요. 파기할 때는 복구 불가능한 방법으로 파기해야 한다는 점을 기억해야 합니다. 저장 매체에 따른 올바른 삭제 방법에 대해서 알아보겠습니다. 2. 개인정보 파기 관련 법령 위에서 살펴본 바와 같이 개인정보를 다루는 시스템이라면 개인정보 수집 목적 달성 또는 보유기간 종료에 따라 개인정보를 파기해야 합니다. 이에 대한 법적 근거는 아래와 같습니다. 정보통신서비스를 제공하는 시스템이라면 추가로 적용해야 할 특례조항도 있습니다. – 개인정보보호법 제21조(개인정보의 파기) – 개인정보보호법 제39조의7(이용자의 권리 등에 대한 특례) – 시행령 제16조(개인정보의 파기방법) – 개인정보의 안전성 확보조치 기준 고시 제13조(개인정보의 파기) – 개인정보보호법 제39조의6(개인정보의 파기에 대한 특례) – 개인정보보호법 시행령 제48조의5(개인정보의 파기 등에 관한 특례) 3. 개인정보의 파기 시점 개인정보 파기에 관련된 아래 조항에서 1항을 보면, 개인정보를 파기해야 하는 시점을 알 수 있습니다. 개인정보 수집 동의 시 명시한 보유기간이 경과됐거나 이용목적의 달성으로 해당 개인정보가 불필요하게 되면 이를 지체없이 파기해야 합니다. 임직원의 퇴사, 이벤트 종료, 숙박 예약 후 체크아웃과 같이 이용목적이 달성된 경우가 그 예시입니다. 또한, 생체정보(얼굴, 지문 등) 추출을 위한 영상정보는 특징점 도출 이후 원본 데이터를 삭제해야 합니다. 보유기간이 정해지지 않은 경우가 바로 삭제 정책이 미흡해 파기할 수 없는 경우인데요. 그렇기 때문에 반드시 해당 정보가 필요한 기간을 정해 정보주체에게 수집동의 받을 때 이를 명시한 후 홈페이지의 개인정보처리방침에도 게시해야 합니다. 이후 보유기간이 지났는지 확인하면서 주기적으로 개인정보를 파기해야 합니다. 또한, 개인정보보호법 제36조, 제37에 의거해 정보 주체가 개인정보의 삭제나 처리정지 등을 요구했을 때에도 지체없이 파기해야 합니다. 개인정보보호법 제39조의7에 의하면 정보통신서비스 이용자가 개인정보 제공에 대한 동의 철회 시에도 이와 마찬가지입니다. 4. 개인정보 삭제 주기에 따른 삭제 프로그램 운영 개인정보의 파기 시점이 도래하거나 정보주체가 개인정보 삭제를 요구하면 파기는 ‘지체없이’...
- 블로그 [보안동향] 컴플라이언스 보안을 지키고 싶다면, 세 가지만 기억하세요! IT 정보시스템 보안점검을 하다 보면, 이제 애플리케이션 취약점은 어느 정도 잘 관리되고 있다고 느끼실 겁니다. 초기 개발단계에서는 시큐어코딩(Secure Coding) 가이드를 만들어 배포하고, 소스 취약점 점검 툴을 통해 소스상 여러 가지 취약포인트를 해결합니다. 시큐어코딩이란 개발하는 소프트웨어가 복잡해짐으로 인해 보안상 취약점이 발생할 수 있는 부분을 보완해 프로그래밍하는 것을 의미합니다. 또한, 테스트 단계에서는 모의 해킹을 통해 기술적 취약점을 제거하는 프로세스가 일반화됐죠. 컴플라이언스(준법경영)관점에서 IT정보시스템에 요구하는 사항들이 잘 지켜지고 있는지 살펴보면 그렇지 못한 것이 현실입니다. 미준수 시 처벌조항이 법률에 명시돼 있음에도 불구하고, 고객 기능요구사항 구현에만 집중한 나머지 보안요구사항이 있었는지도 모르는 프로젝트 현장이 있을 수 있습니다. 특히, 개인정보를 다루는 시스템은 이러한 컴플라이언스에 명시된 요구사항에 더욱 주의를 기울일 필요가 있습니다. 1. 컴플라이언스 요구사항은 언제 식별하는 게 좋을까요? 컴플라이언스 요구사항, 특히 보안요구사항은 분석단계에서 식별한 후 설계 단계에 반영돼야 합니다. 개발이 어느 정도 진행된 상태나 테스트 단계에서 수정해 반영하려고 하면 수정 영향도가 너무 크기 때문입니다. 따라서 프로젝트 초기에 컴플라이언스 요구사항을 식별해 대응하는 것이 무엇보다 중요합니다. 개인정보보호법 개인정보 안정성 확보 조치에서는 아래와 같이 명시하고 있습니다. 제8조(접속기록의 보관 및 점검) ① 개인정보처리자는 개인정보취급자가 개인정보처리시스템에 접속한 기록을 1년 이상 보관ㆍ관리해야 한다.다만, 5만명 이상의 정보주체에 관하여 개인정보를 처리하거나, 고유식별정보 또는 민감정보를 처리하는 개인정보처리시스템의 경우에는 2년 이상 보관ㆍ관리해야 한다. 개인정보를 다루는 담당자가 업무를 수행할 때 개인정보를 보유하고 처리하는 시스템은 누가, 언제, 어디서, 무엇을, 무슨 사유로 활용했는지 기록을 남겨야 합니다. 이를 지키지 않았는데 개인정보 유출이 발생했다면 2년 이하의 징역 또는 2,000만원 이하의 벌금이 부과되는데요. 개인정보 유출이 발생하지 않았더라도 이러한 미조치가 적발된다면 3,000만원 이하의 과태료 처분을 받을 수 있습니다. 개인정보 접속기록을 보관해야 한다는 점은 분석단계에서 인지돼야 합니다. 이후 설계단계에서는 이러한 기능을 응용 프레임워크 단계에서 구현할지 공통함수를 만들어 처리할지 설계해야 하죠. 그리고서 개발단계에서 관련 담당자에게 구현사항을 가이드한다면 이러한 요구사항이 매끄럽게 구현될 수 있습니다. 개인정보 접속기록이 남지 않았다는 사실을 프로젝트 마지막 단계인 테스트 단계에서 인지한다면 두 세배의 시간과 노력을 들여 수정해야 합니다. 급하게 개인정보처리 화면을 식별하고, 기존 설계사항을 분석하고 검토해서 해당 프로그램을 수정해야 하죠. 따라서 컴플라이언스 보안요구사항은 프로젝트 조기에 식별하고 설계, 개발에 반영하는 것이 무엇보다 중요합니다. 2. 컴플라이언스 보안요구사항은 어떻게 식별해야 할까요? 컴플라이언스 보안요구사항 분석은 식별 경험이 많고, 요구사항별로 대응 방안을 수립한 경험이 있는 보안 전문인력이 수행하는 것이 중요합니다. 개인정보보호법 개인정보 안정성 확보조치를 보면 개인정보 접속기록을 남기는 것에서 그치지 않는다는 것을 알 수 있는데요. 아래와 같이 추가로 보관 및 점검을 요구하고 있습니다. 제8조(접속기록의 보관 및 점검) ②개인정보처리자는 개인정보의 오ㆍ남용, 분실ㆍ도난ㆍ유출ㆍ위조ㆍ변조 또는 훼손 등에 대응하기 위해 개인정보처리시스템의 접속기록 등을 월 1회 이상 점검하여야 한다. 특히 개인정보를 다운로드한 것이 발견되었을 경우에는 내부관리 계획으로 정하는 바에 따라 그 사유를 반드시 확인해야 한다. ③ 개인정보처리자는 개인정보취급자의 접속기록이 위ㆍ변조 및 도난, 분실되지 않도록 해당 접속기록을 안전하게 보관해야 한다. 먼저 ③번 조항을 살펴보면, 개인정보 접속 기록이 위변조 및 도난, 분실되지 않도록 요구하고 있습니다. 그렇다면 이러한 위협을 막기 위해서는 어떻게 해야 할까요? 여러 방법이 있겠지만 접속기록을 파일 또는 DB에 저장할 경우, 해시함수를 이용해서 로그 데이터 건별로 해시값을 이용한 MAC값을 만들어 별도 테이블에 보관하고, 접근을 통제해 위변조 여부를 확인하는 방법이 있습니다. 다소 비용이 들지만 간편한 웜(Write Once Read Many,WORM) 디스크를 이용하는 방법도 있는데요. WORM 디스크는 한 번 기록된 정보는 수정할 수 없는 데이터 스토리지를 말합니다. 이렇게 비인가자가 접근할 수 없도록 접근통제 솔루션을 이용해 접속 이력 테이블 또는 파일을 보호하는 것이 중요합니다. 개인정보처리자는 이처럼 보안요구사항을 종합해서 빈틈없이 보안요건을 정의하고, 대응 방안을 설계자들에게 다각도로 제시해 해당 시스템에 가장 적합한 대응 방안을 수립해야 합니다. 다음으로 ②번 조항을 살펴보면 개인정보처리자가 개인정보 접속기록을 월 1회 이상 점검해야 한다고 명시하고 있습니다. 하지만 이를 시스템 구축단계가 아닌 운영단계에서 지켜야 할 사항이라고 생각해 넘어가는 경우가 많은데요. 곰곰이 생각해보면 그렇지 않습니다. 구축단계에서 개인정보 접속이력을 잘 저장해야 운영단계에서 원활하게 모니터링이 진행될 수 있죠. 편하게 조회할 수 있도록 화면을 설계하고, 일정 기간 동안 일정 횟수 이상 조회하거나 업무시간 외에 조회하는 상황을 확인하는 기능을 구현하면 운영단계에서 개인정보를 편리하게 사용할 수 있습니다....
- 블로그 [보안동향] LG CNS Security Summit 2022 다시보기! LG CNS Security Summit 2022에서는 국내외 유수의 보안 기업, 학계, 정부부처 등 각계 각층의 최고의 보안 전문가들을 모시고, AI보안, OT보안, 클라우드 보안 등 IT 신기술에 대한 최신의 보안 트렌드와 보안 전략을 제시합니다. 최신 보안 정보를 들을 기회를 놓치신 분들을 위해 LG CNS가 ‘LG CNS Security Summit 2022 다시보기!’ 콘텐츠를 마련했습니다. 이번 행사를 다시 보기 원하시는 분들과 개인 사정으로 당일 참석이 어려우셨던 분들을 위해 발표 영상과 발표자료를 제공해드립니다. 아래 이미지를 클릭해 확인해주세요! 글 ㅣ LG CNS 홍보팀
- 블로그 코카콜라, 넷플릭스도 도입한 ‘Zero Trust’ 5가지 구현 기술은? Zero Trust Network Access(ZTNA) 제로 트러스트(Zero Trust)는 ‘아무것도 신뢰하지 않는다’는 것을 전제로 한 사이버 보안 모델로,사용자나 기기가 접근을 요청할 때 철저한 검증을 실시하고, 검증이 이뤄진 후에도 최소한의 신뢰만 부여해 접근을 허용하는 방식입니다. ZTNA (Zero Trust Network Access)는 ‘초세분화 적응형 인증 및 컨텍스트(Context) 인식 정책’으로, 원격 위치 또는 단말기에 클라우드 혹은 기업 데이터 센터에서 호스팅 되는 프라이빗 애플리케이션을 안전하게 제공하는 방법입니다. LAN(Local Area Network)에 대한 완전한 접근을 허용하는 VPN(Virtual private network)과 달리 ZTNA는 사용자에게 명시적으로 부여된 서비스의 접근만 허용합니다. ZTNA는 사용자가 ZTNA 서비스에 대해 인증한 후 접근이 설정됩니다. 그런 다음, 암호화된 보안 터널을 통해 사용자를 대신해 ZTNA 서비스가 애플리케이션에 대한 접근을 제공하는데요. 이렇게 하면 공개적으로 볼 수 있는 IP주소를 차단해 기업 애플리케이션과 서비스에 추가 보호를 도입할 수 있습니다. 또한, ZTNA는 다크 클라우드 개념을 활용해 사용자가 접근 권한이 없는 애플리케이션과 서비스를 볼 수 없도록 차단합니다. 기업은 주로 아래 4가지 중 하나를 해결하기 위해 ZTNA를 도입합니다. 1) 관리가 어려운 VPN 대체VPN은 불편하고 느리며, 보안에 취약하고 관리가 어렵습니다. 가트너는...
- 블로그 [보안동향] 편하면 끝? 생체정보 활용 시 주의해야 할 3가지! 스마트폰과 같은 모바일 기기의 사용이 증가하면서 지문이나 얼굴, 홍채, 정맥 등의 생체정보를 활용한 기능이 대중화되고 있습니다. 생체정보는 안전하면서도 따로 기억하거나 가지고 다닐 필요가 없어 편리하다는 장점이 있는데요. 이러한 장점으로 인해 잠금 해제, 출입 통제, AI 음성인식 서비스 등 여러 분야에서 자주 활용되고 있습니다. 그러나, 생체정보는 변경이 불가능하다는 특성이 있기 때문에 유출될 경우 심각한 피해를 볼 수도 있습니다. 이러한 피해를 예방하기 위해 개인정보위원회에서는 ‘21년 9월 개정한 “생체정보 보호 가이드라인’에서 생체인식정보 보호 조치를 통해 생체정보의 안전한 활용 방법을 제시하고 있습니다. 여기서 ‘생체인식정보‘란, 생체정보 중 특정 개인을 인증·식별하기 위한 목적으로 처리되는 정보를 말합니다. 생체인식정보는 다시 ‘원본정보’와 ‘특징정보’로 나뉘는데요. 개인을 인증 또는 식별하기 위한 목적으로 입력장치 등을 통해 수집·입력되는 것이 ‘원본정보’이고, 이로부터 특징점을 추출하는 등의 기술적 수단을 통해 생성되는 것이 ‘특징정보’입니다.「개인정보 보호법」 시행령 제18조 제3호에서는 민감정보를 ‘개인의 신체적, 생리적, 행동적 특징에 관한 정보로서 특정 개인을 알아볼 목적으로 일정한 기술적 수단을 통해 생성한 정보’라고 규정하고 있습니다. 이에 따라 특징정보는 민감정보에 해당하므로 「개인정보 보호법」 제23조(민감정보의 처리 제한)이 적용됩니다. 이번 글에서는 개인정보보호 위원회의 ‘생체정보 보호 가이드라인’ 중 ‘생체인식정보 보호조치’ 내용을 개인정보의 흐름에 따라 단계별로 알아보겠습니다. 1. 수집 단계 “특징정보는 별도의 동의를 받아야” 특징정보는 민감정보로 분류되기 때문에 수집 시 다른 개인정보와는 별도로 동의를 받아야 합니다. 수집·이용 동의서에는 ①수집·이용 목적, ②수집 항목, ③보유·이용기간, ④동의를 거부할 권리가 있다는 내용이 들어있어야 하는데요. 동의 거부에 따른 불이익이 있는 경우, 그 불이익의 내용이 포함돼야 합니다. 원본정보는 개인정보 침해 위험성이 크기 때문에, 특징정보 생성이 완료돼 원본정보의 수집·이용 목적이 달성되면 이를 지체 없이 파기하는 것이 원칙힙니다.그러나 필요에 따라 원본정보를 보관해야 하는 경우, 수집·이용 동의를 받을 때 목적과 보유기간 등을 구분해서 안내해야 하는데요.다른 필수 동의 사항과 같이 일괄 동의 받는 것도 가능합니다. 법적 의무 사항은 없지만, 생체인식정보가 수집·입력될 때 위·변조된 생체인식정보를 이용한 공격에 대한 보안대책을 마련하는 것이 권고됩니다. 여기서 말하는 위·변조된 생체인식정보의 예시로는 인공 지문, 캡처된 얼굴·홍채 이미지, 녹음된 음성 등이 있습니다. 생체인식정보의 위·변조 여부를 탐지하는 방법은 하드웨어 방식과 소프트웨어 방식이 있는데요. 하드웨어 방식으로는 온도와 맥박을 감지하거나,...
- 블로그 [융합보안] 입주사vs건물주, 물리보안 구축 시 고려사항은? 여러분의 현재 주거 형태는 아파트인가요, 아니면 단독 주택인가요? 물론 다세대 주택일 수도 있을 겁니다. 국토교통부가 발표한 서울시 주거실태 현황 자료를 보면 아파트에 거주하는 시민의 비율이 가장 높은 것으로 나타나는데요. 그렇다면 다른 주택 유형에 비해 아파트에 거주하는 비율이 높은 이유는 무엇일까요? 이는 투자가치, 보안성, 편의성 등 단독주택에 비해 아파트가 가진 장점 때문입니다. 이 중 보안성에 대해 살펴보겠습니다. 아파트에는 CCTV와 경비요원 등 기본적인 보안시스템이 갖춰져 있죠. 무엇보다 저층을 제외하고는 외부로부터 침입이 어려운 구조적 특성이 있습니다. 그런데 만약 여러분이 아파트의 보안수준에 만족하지 못한다면 어떨까요? 여러분이 공동 현관문에 최첨단 얼굴인식 시스템을 설치하고 싶다고 해서 바로 설치할 수는 없을 겁니다. 아파트에는 기본적인 보안시스템이 구축돼 있지만, 개인이 원한다고 해서 함부로 장비를 추가 설치하기는 어렵기 때문이죠. 반면, 단독 주택은 주인 마음대로 보안 시스템을 추가할 수 있습니다. 이러한 상황은 상업용 건물의 보안시스템 설치에도 유사하게 적용될 수 있습니다. 여러 회사가 입주해 있는 건물에 특정 회사를 위한 보안시스템을 구축해야 하는 경우가 발생할 수 있는데요. LG그룹사 사례를 통해 물리보안 시스템 구축 PM의 관점에서 고려해야 할 사항을 알아보겠습니다. 입주사 vs 건물주 하나의 회사가 전용으로 사용하는 건물과 다르게, 여러 회사가 입주한 건물에는 입주회사뿐만 아니라 건물주와 협의를 통한 의사결정이 필요합니다. 일반적으로 신규 입주 회사가 건물의 몇 층을 사용하게 될지 계획이 세워지면 입주 전에 보안시스템 구축이 완료돼야 하죠. 그러나 계약 당시에는 보안시스템 구축 같은 세부 사항까지는 고려하지 못하는 게 현실인데요. 그렇기 때문에 보안시스템 설계 또는 구축과정에서 예상치 못한 어려움에 직면할 수도 있습니다. 따라서 보안시스템 설계자는 주 출입구를 포함해 입주 층까지 임직원 동선은 어떻게 구성되는지 최우선으로 파악해야 합니다. 보통 오피스 건물은 고층 건물인 경우가 많기 때문에 엘리베이터를 운행하게 되는데요. 입주사 전용으로 엘리베이터를 사용할 수 있다면 다행이지만, 불가능한 상황에서는 건물 주 출입구에서 보안시스템 운영에 많은 제약이 발생할 수밖에 없습니다. 엘리베이터 등 출입 동선이 확인되면 X-Ray 등 보안 검색시스템 및 안내데스크 배치 도면을 바탕으로 입주사와 건물주 간 협의와 의사결정이 진행돼야 합니다. 최근 사례로 보면, 건물 시공단계에서부터 스피드게이트와 같은 기본 보안시스템을 고려해 설치했지만, 보안 검색 장비를 추가 배치하기에는 공간이 협소한 경우가 있었습니다. 이에 따라 입주사의 보안 검색 장비 구성 표준안을 적용치 못하게 됐는데요. 결국, 해당 구성의 취약점을 보완하기 위한 새로운 대안을 고민해야 하는 상황을 발생하게 됐고, 이로 인해 입주사와 건물주 간 협상 및 의사결정에 예상치 못한 시간을 소요하게 됐습니다. 이미 설치된 보안장비는 어찌할 것인가? 앞서 언급했지만, 어느 정도 규모가 있는 오피스 빌딩은 스피드게이트, 출입 통제 시스템, 영상감시시스템 등 기본적인 보안시스템이 건물 설계에 반영돼 있습니다. 기본으로 설치된 보안시스템만으로 입주사가 만족할 수도 있지만, 입주사 전용 보안 검색시스템, 출입 통제 시스템, 영상감시시스템 설치를 요구할 수도 있습니다. 만약, 입주사만의 독자적인 출입 통제 시스템을 구축해야 하는 경우, 기존에 설치된 스피드게이트를 재사용할지 철거할지 결정해야 하는데요. 이미 설치된 장비로 인해 장비 구성 변경 또는 추가가 어려울 수도 있습니다. 출입 단말기는 입주 층 주 출입구 비상계단 등에도 설치돼 있습니다. 기존 장비를 철거하지 않고 유지해야 한다면 신규 단말기 위치 선정에 어려움을 겪을 수 있습니다. 따라서 기존 장비와 신규단말기 간 도어락 컨트롤 및 문 상태 정보를 건물공통 출입시스템에 연계하는 방안을 마련해야 합니다. A사의 경우, 입주사가 독자적인 출입 통제 시스템을 구축했지만, 건물 전체를 관리하는 방재센터에서 출입문 상태 모니터링을 위해 건물 공통으로 기존 설치된 출입 단말기를 철거할 수 없도록 했습니다. 오피스건물은 보안 검색시스템 구축에 필요한 공간을 확보하기 어려울 수도 있는데요. 보안 검색시스템은 보통 빌딩의 공용구역과 입주사 전용 구역의 경계에 설치되기에 필연적으로 입주사와 건물주와 이해가 충돌할 수밖에 없습니다. 따라서 의사결정에 더욱 많은 시간이 소요될 수 있습니다. 그리고 일반적으로 임대인은 계약조건에 원상복구 조건을 포함하기도 합니다. 그래서 신규 장비 설치 또는 변경 시에도 향후 원상복구를 고려해 시공해야 하므로 예상치 못한 난관에 부딪히기도 하죠. 만약 철거한 장비가 있다면 향후 원상복구를 고려해 철거 장비 보관 및 인수인계 작업이 필요할 수도 있습니다. 마지막으로, 각 층에는 설비 관리를 위한 EPS실 및 TPS실이 존재하는데요. 대부분 빌딩 공통시설의 운영을 목적으로 하고 있습니다. 여기에 입주사만의 전용 장비를 설치할 수 있도록 허용한다고 하더라도 운영/유지보수 인력의 출입 권한 관리 등 문제 발생 시 책임소재의 리스크도 고려해야 합니다. A사는 각층에 전용 EPS, TPS실을 신설해 출입 통제 및 영상감시 장비를 운영하는 것으로 설계에 반영했습니다. 간과하기 쉬운 업체 관계 기존 장비가 설치돼 있는 경우, 해당 장비를 재사용하든 철거를 하든 해당 장비 설치업체의 협조는 필수적인데요. 이에 대한 비용도 사전에 반영해야 합니다. 예를 들어, 하자보수 기간 내에 있는 장비의 경우, 기설치업체의 협조 없이 스피드게이트의 카드리더기를 바꾼다면 해당 업체는 하자보수 면책 사유를 주장할 수도 있습니다. 또한, 유지보수 기간에 있더라도 문제처리 관련 책임소재 이슈가 발생할 수도 있죠. 이외에도 향후 원상복구를 고려한 장비 철거 또는 변경 작업에도 기존 설치업체의 협업이 요구됩니다. 따라서, 시스템 구축에 착수하기 전에 시공 작업에 참여한 협력업체들의 연락처를 확보하는 것이 중요합니다. 이번 글에서는 한 건물에 여러 회사가 입주한 경우 물리보안 시스템 구축 시 필요한 고려사항을 살펴보았습니다. 입주사 전용 건물에 보안시스템을 구축하는 것에 비해 더 복잡한 의사결정 구조와 다양한 이해관계자들이 존재한다는 것을 알 수 있었는데요. 물리보안 시스템 구축에는 보안시스템 설계자 또는 PM의 세심한 관심이 필요하다는 점을 기억해야 합니다....
- 블로그 [보안동향] 아직도 신분증 들고 다니세요? 폰만 있으면 본인인증 가능! 여러분은 모바일기기에서 사용자 인증 수단으로 어떤 것을 사용하시나요? 우리는 오랜 기간 PC에서 아이디와 패스워드로 사용자 인증을 진행해 왔습니다. 공인인증서(현 공동인증서)를 PC에 저장해서 사용했고, 그러다가 USB 저장기기에도 인증서를 저장해 사용할 수 있게 됐죠. USB를 통해 지문인식기기 등도 연결해서 사용해 왔습니다. 이후, 스마트폰의 등장과 확산은 PC에만 있던 인증 수단을 모바일에서도 사용할 수 있도록 만들었습니다. 모바일 기기에 인증서를 저장할 수 있게 됐고, 별도의 장치 없이 스마트폰만 있으면 언제든지 지문인식, 안면인식을 수행할 수 있게 됐습니다. 신분증도 마찬가지입니다. 그동안 주민등록증, 운전면허증 등의 신분증과 함께 회사 사원증도 플라스틱으로 만들어진 실물을 가지고 다녀야 했죠. 신원 확인이 필요하면 신분증을 꺼내서 눈으로 직접 인증받아야 했습니다. 그러나, 최근에는 이러한 신분증도 스마트폰으로 들어가기 시작했습니다. 이제는 두꺼운 지갑을 들고 다니지 않아도 스마트폰만 있으면 신분을 증명하는 것이 가능해졌는데요. 모바일에서도 신분증을 보관, 사용할 수 있게 해주는 기술이 바로 ‘DID 인증’ 기술입니다. DID(Decentralized Identity/Distributed Identity, 탈중앙화 신원 증명) 는 블록체인 기술 기반으로 구축한 신원 증명 서비스입니다. 지갑에서 주민등록증을 꺼내듯 블록체인 지갑에서 DID를 제출해 신원을 증명할 수 있죠. 기존 중앙집권화된 방식과 비교해 신원 확인 과정에서 개인이 자기 정보에 완전한 통제권을 행사하는 것이 특징인데요. 이를 분산 아이디 또는 탈중앙화 신원확인(신원 증명), 자기 주권 신원 증명(Self-Sovereign Identity)이라고도 합니다. LG CNS는 라온시큐어와 함께 DID 플랫폼을 기반으로 한 우리나라 최초 디지털 신분증인 ‘모바일 운전면허증’ 구축을 완료하고 발급 및 시범 운영을 시작했습니다. 블록체인 기술을 기반으로 기존 플라스틱 신분증의 문제점인 분실 위험과 위·변조를 해결하는 동시에 온오프라인에서 사용할 수 있는 시스템 구축에 힘을 쏟았는데요, 이를 통해 상대방이 필요로 하는 정보만 제공할 수 있도록 지원해 개인정보 유출을 방지할 수 있습니다. 실제로 차량을 빌릴 때는 운전 자격 정보만, 담배나 주류를 구매할 때는 생년월일만 노출이 가능합니다. LG CNS외에도 다양한 국내외 기업들이 DID 인증 서비스를 개발·운영 중입니다. 이번 글에서는 최근 DID 인증 동향에 대해서 살펴보겠습니다. DID 인증, 누가 주도하고 있을까요? 국내에서는 이미 기업, 금융권, 공공영역까지 DID 인증 시장을 선점하기 위해 다양한 업체들이 경쟁을 벌이고 있습니다. △아이콘루프가 주도하는 마이아이디(MyID), △블록체인 기술기업 코인플러그가 이끄는 마이키핀(MyKeepin)이 주도하고 나머지 통신사가 합류한 이니셜DID, △보안기업 라온시큐어가 중심인 DID얼라이언스 등이 DID를 주도하는 대표적인 그룹입니다. 정부에서도 모바일 공무원증을 시작으로 운전면허증, 장애인 복지카드 등으로 DID 적용을 확대하고 있습니다. 이렇게 DID 관련 업체, 얼라이언스들은 각자가 가진 기술을 발전시키고, 다양한 서비스를 꾸준히 시장에 내놓으면서 영향력을 확대하고 있습니다. 또한, 호환성과 상호운용성을 확보해야 한다는 사실을 잘 알고 있기 때문에 W3C(World Wide Web Consortium) DIF(2017년 설립된 국제표준기구로, 분산 신원확인 기술의 표준화와...
- 블로그 [보안동향] 성공적인 ‘컨테이너 플랫폼’ 운영을 위한 5가지 보안Tip! 과거 대부분의 기업용 애플리케이션은 하나의 거대한 서비스 형태(모놀리식 아키텍처, Monolithic Architecture)로 개발됐습니다. 모놀리식 아키텍처는 개발·관리가 용이하다는 장점이 있지만,시스템 규모가 커질수록 복잡도가 증가하는데요. 이에 따라 코드의 이해와 분석이 어려워지고 작은 수정사항에도 시스템 전체를 다시 개발(build)하고, 배포해야하는 비효율이 발생해 시스템의 개선과 확장이 어렵다는 단점이 존재합니다. 이러한 단점을 극복하기 위해 등장한 개념이 마이크로서비스 아키텍처(MSA, Microservices Architecture)입니다. 경량화되고 독립적인 여러 개의 서비스를 조합해 애플리케이션을 구현하는 방식인데요. 서비스마다 자체 데이터베이스를 가지고 동작하기 때문에 개발부터 빌드·배포까지 효율적으로 수행할 수 있습니다.기업 입장에서는 개발과 유지관리에 드는 시간과 비용을 줄일 수 있어 MSA로의 전환이 대세가 되고 있습니다. 국내업계는 MSA 도입과 전환에 대해 2013년부터 검토를 시작했습니다. 쿠팡, 배달의민족, 11번가 등 스타트업이 선도적으로 MSA를 채택했습니다. 트래픽 증가에 따라 데이터베이스, 서버를 증설해야하는 기존 모놀리식 구조의 한계를 극복하고 MSA로의 전환을 완료했는데요. 이들 기업은 MSA 이후 개발단계의 속도뿐만 아니라 주문 결제 서비스 대고객 응답 속도 개선이 이뤄졌다고 스스로 평가하고 있습니다. 오늘의 주제는 컨테이너의 보안위협과 대응방안인데 왜 마이크로서비스로 이야기를 시작했을까요? 마이크로서비스를 가장 잘 구현할 수 있는 형태의 플랫폼이 컨테이너 방식이기 때문입니다. 국내외 기업이 점차 더 많은 서비스를 MSA 방식으로 개발하는 흐름 속에서 이를 뒷받침하는 기반 기술로서 컨테이너 플랫폼 선택 또한 자연스럽게 증가하고 있습니다. 지금부터 도커(Docker), 쿠버네티스(Kubernetes)로 구체화된 컨테이너 플랫폼의 개념을 간략하게 소개하고, 컨테이너의 보안 위협과 대응 방안에 관해 살펴보겠습니다. 컨테이너, 도커, 쿠버네티스 서버가상화 기술은 하이퍼바이저(Hypervisro)를 활용한 가상머신에서 게스트운영체제(OS)없이 바이러니(Bin)/라이브러리(Lib)와 애플리케이션으로 구성된 컨테이너로 발전하고 있습니다. 기존의 가상머신(VM, Virtue Machine) 서버는 물리적인 서버 위에 하이퍼바이저,그 위에 각각의 게스트 OS가 설치된 VM을 구동하는 형태입니다. 가상머신은 하이퍼바이저에 의해 서버 내 CPU, 메모리, 디스크, 네트워크 등의 자원을 분할공유해 사용합니다. 컨테이너형 서버는 물리적인 서버 위에 서버운영체제(OS), 그 위에 도커 엔진 또는 컨테이너 런타임이 설치되며,그 위에 여러 개의 컨테이너가 동작하는 형태입니다. CPU, 메모리, 디스크, 네트워크와 같은 운영체제의 자원을 필요한 만큼 격리해 컨테이너에 할당하는 형태인데요. 여기서 컨테이너란 일종의 격리된 공간으로서, 별도의 게스트OS 없이 런타임과 바이너리, 데이터만으로 애플리케이션이 구동되는 환경을 가리킵니다. 서두에 언급한 마이크로서비스 아키텍처는, 이와 같은 컨테이너 방식의 플랫폼을 활용해 거대한 애플리케이션을 기능별로 쪼개고, 개별 컨테이너에 경량화된 단위 서비스를 배포합니다. 또한, 컨테이너별 변경 사항이 다른 서비스에 영향 미치지 않아서, 전체 서비스를 하면서도 독립적으로 구성할 수 있습니다. 도커는 리눅스 진영의 오픈소스 프로젝트로, 컨테이너 개념을 구체화한 도구입니다. 쿠버네티스는 엔터프라이즈 버전의 컨테이너 및 도커를 관리하는 도구입니다. 부연 설명하면, 실행 이미지를 컨테이너에 띄우고 실행하는 기술이 ‘도커’이고, 이러한 도커를 기반으로 복잡한 컨테이너들을 관리하는 서비스가 ‘쿠버네티스’입니다. 쿠버네티스는 △컨테이너의 생성과 소멸 △시작 및 중단 시점 제어 △스케줄링 △로드 밸런싱, △클러스터링 등 컨테이너로 애플리케이션을 구성하는 모든 과정을 관리하는 컨테이너의 오케스트레이션 도구입니다. 마스터(MASTER): 쿠버네티스 노드를 제어하는 머신. 모든 태스크 할당을 시작함 노드(NODE): 할당된 태스크를 요청대로 수행하는 시스템 포드(POD): 단일 노드에 배포된 하나 이상의 컨테이너 그룹. 포드에 있는 모든 컨테이너는 IP 주소,...
- 블로그 LG CNS Security Summit 2022가 전하는 최신 보안 트렌드! 디지털 전환(DX)은 이제 기업 생존의 필수요소로 자리 잡았습니다. LG CNS Security Summit 2022에서 각계각층 최고의 보안 전문가들을 모시고, 최신 보안 트렌드와 보안 전략을 제시해 드립니다. 지금 바로 사전등록하고, 보안 리스크를 점검해 보세요! LG CNS가 미래 보안 리스크를 해결할 새로운 보안 전략을 제시합니다. 글 ㅣ LG CNS 홍보팀
- 블로그 [보안동향] 안전한 소프트웨어 개발, 보안 취약점 점검이 답이다! 이번 글에서는 4년 만에 다시 공개된 OWASP TOP 10 (2021)에서 변동된 취약점 우선순위를 살펴보고, 두 항목을 비교해보도록 하겠습니다. 마지막으로 안전한 소프트웨어 개발 시 주의 깊게 봐야 할 소프트웨어 보안 약점(취약점)은 무엇이 있는지 정리해보겠습니다. OWASP TOP 10 (2021) ‘OWASP TOP 10’은 OWASP에서 3~4년에 한 번씩 비정기적으로 발표하는 문서인데요. 가장 많이 익스플로잇 되는 취약점 유형이 무엇인지 순위대로 정리한 것입니다. 2021년 9월, 4년 만에 초안이 발표됐습니다. 아직 최종본은 아니지만, 특이점들에 대해 미리 살펴보겠습니다. 2017년 발표된 항목 대비 추가 및 변동된 순위를 보면 아래와 같습니다. 2021년 항목에 3개의 신규 항목이 추가됐으며, 2017년 항목 중 4개 항목이 이름과 범위가 변경되고, 그 외 일부 통합되며 순위 변동이 일어난 것이 눈에 띕니다. 1위를 차지한 ‘취약한 접근통제’와 함께, ‘암호화 오류’, ‘인젝션’ 항목이 웹 애플리케이션에서 가장 빈번하게 나타나는 취약점 1~3위를 차지했으며, ‘크로스 사이트 스크립팅’이 ‘인젝션’ 항목으로 통합됐습니다. 신규 추가됐으나 4위를 차지한 ‘안전하지 않은 설계’ 항목은 소프트웨어 개발 보안 생명주기(Secure Software Development Lifecycle)의 설계 단계에서 위협 모델링 없이 구현되거나 미흡하게 설계돼 발생하는 보안 취약점을 설명하고 있습니다. 다음으로 5위인 ‘잘못된 보안 구성’ 항목은 ‘XML 외부객체’ 항목이 통합됐고, 6위 ‘오래된 취약점이 있는 구성요소 사용’, 7위 ‘사용자 식별 및 인증 오류’, 9위 ‘보안로그 및 모니터링 오류’ 항목은 이름이 변경되며 취약점이 더 명확해지고 범위가 넓어졌습니다. 8위에 오른 신규 추가된 ‘소프트웨어와 데이터 무결성 오류’에는 ‘안전하지 않은 역직렬화’ 항목을 포함해 데이터 무결성 검증을 위한 올바른 전자서명 활용에 관한 내용도 설명하고 있습니다. 마지막으로 ‘서버측 요청 위조’ 항목이 10위에 올랐는데요. 앞서 살펴본 행정안전부의 소프트웨어 개발 보안 항목, [1. 입력데이터 검증 및 표현] 영역의 ’12. 서버사이드 요청 위조’와 동일한 것으로, 새롭게 순위에 오른 만큼 더욱 주의해야 할 취약점이 됐습니다. 소프트웨어 보안 약점과 OWASP TOP 10 (2021) 아래 표는 앞서 살펴본 소프트웨어 개발 보안 구현단계에서의 49개 보안 약점(이하 49개 보안 약점이라 함)과 OWASP TOP 10 (2021) 초안을 비교한 것입니다. OWASP TOP 10에서 설명하는 각 취약점 영역의 범위가 넓어 49개 보안 약점이 상당수 중복됐는데요. A09:2021 ‘보안로그 및 모니터링 오류’ 취약점의 경우 주로 테스트 및 운영 단계에서 서버 보안 설정 또는 주기적인 점검이 필요한 취약점을 설명한 것입니다. 이는 49개 보안 약점과 연결되지는 않았으나, 구현단계에서부터 개인정보 보호법 등 관련 법에 따라 접속기록 보관을 하는 등의 주의가 필요하므로, 역시 주요한 취약점입니다. 맺음말 최근 제로데이 공격, 웹사이트 해킹 등의 보안패치 발표 전에 소프트웨어에 내재된 보안취약점을 악용하는 사이버공격이 꾸준히 증가하고 있습니다. 안전한 정보시스템 구축을 위해 보안 담당자와 개발자 등은 이를 대비해 최신 보안 방안이 반영된 소프트웨어 개발 보안 가이드 및 OWASP TOP 10을 참고해 시큐어 코딩(Secure Coding)을 적용해야 합니다. 또한, 주기적인 취약점 점검 및 개선 활동을 수행해야 합니다. [참고] https://www.law.go.kr/행정규칙/행정기관및공공기관정보시스템구축·운영지침owasp.org/www-project-top-ten 글 | LG CNS 사이버시큐리티팀 조민아 책임
- 블로그 [보안동향] 변화하는 소프트웨어 보안, 최근 주요 취약점은? 기본적으로 정보시스템 사업 수행 시 안전한 소프트웨어 개발을 위해 기준으로 삼는 국내 대표 가이드는 행정안전부 고시(행정기관 및 공공기관 정보시스템 구축 · 운영 지침)에 따라 한국인터넷진흥원(KISA)에서 발간한 ‘소프트웨어 개발 보안 가이드’가 있으며, 국외 대표 참고 기준으로는 OWASP(The Open Web Application Security Project)의 ‘TOP 10 Web Application Security Risks(이하 OWASP TOP 10이라 함)’가 있습니다. 지난 2021년 1월 19일 개정된 ‘행정기관 및 공공기관 정보시스템 구축 · 운영 지침’에서 소프트웨어 개발 보안과 관련해 강화된 내용을 함께 알아보겠습니다. 행정기관 및 공공기관 정보 시스템 구축 · 운영 지침과 소프트웨어 보안 약점 먼저 살펴볼 행정기관 및 공공기관 정보시스템 구축 · 운영 지침(이하 지침이라 함)은 전자정부법 제45조 제3항에 따라 행정기관 등의 장이 정보시스템을 구축 · 운영하면서 준수해야 할 기준, 표준 및 절차와 동법 제49조 제1항에 따른 상호운용성 기술평가에 관한 사항을 정한 것입니다. 정보시스템 사업 수행 시 프로젝트 관리 및 보안 준수에 있어 위 지침에 따라 수행하게 됩니다. 지침이 개정된 이유를 보면, 소프트웨어 보안성 강화 및 통합인증 공통 기반을 적용하도록 해 국민이 전자정부 서비스를 안전하고 편리하게 이용하고, 관련 법 · 제도 변경 사항 등을 반영하기 위함이라 설명돼 있습니다. 보안 관련된 내용만 살펴보면 아래와 같습니다. 보안성 강화 부분에서 국내외 최신 보안 약점을 반영해 소프트웨어 개발 보안 제도를 강화한다는 것을 알 수 있습니다. 또한, 지난 2020년 12월 전면 개정된 전자서명법을 반영해 공동인증서와 민간인증서 발급기관을 포함하는 ‘통합인증 공통 기반’ 적용이라는 내용이 추가된 것을 확인할 수 있습니다. 지침 제50조(소프트웨어 개발 보안 원칙)에 따라 정보시스템 사업 진행 시 개발자가 설계 및 구현 단계에서 반드시 개선 조치해야 할 소프트웨어 보안 약점 기준(지침 별표3)도 개정된 이유에 의해 변경됐습니다. 2019년 발령된 고시 대비 변경된 내용을 비교해 살펴보겠습니다. 구현단계 소프트웨어 개발 보안 항목은 총 47개에서 49개로 늘어났습니다. 신규 추가된 항목은 6개이며, 8개 항목이 통합돼 4개 항목으로 축소됐습니다. [1. 입력 데이터 검증 및 표현] 영역에서 신규 추가된 항목은 ‘2. 코드 삽입’, ‘8. 부적절한 XML 외부 개체 참조’, ‘12. 서버사이드 요청 위조’ 3개이며, ‘9. XML 삽입’은 기존의 ‘Xquery삽입’, ‘Xpath삽입’ 보안 약점이 통합된 것입니다. ‘2. 코드 삽입’ 보안 약점은 ‘1. SQL 삽입’, ‘3. 경로 조작 및 자원 삽입’, ‘5. 운영체제 명령어 삽입’ 등과 같은 삽입 취약점과 같은 개념으로 eval()과 같은 함수로 이루어진 코드(명령어)가 검증되지 않고 실행 가능할 때 발생할 수 있는 보안 약점입니다. ‘8. 부적절한 XML 외부 개체 참조’ 보안 약점은 OWASP TOP 10 (2017)에서도 발표됐던 항목으로 취약한 XML 파서가 외부 개체를 삽입한 XML을 검증 없이 그대로 처리하게 될 시 발생할 수 있는 보안 약점입니다. ’12. 서버사이드 요청 위조’ 보안 약점은 서버사이드에서 이루어지는 요청을 검증하지 않아 의도하지 않은 서버로 요청이 가게 되거나 요청이 변경될 수 있는 보안 약점입니다. 크로스사이트 요청 위조와 유사하지만, 클라이언트가 아닌 서버에 영향을 줘 파급력이 크며, OWASP TOP 10 (2021)에도 새롭게 순위를 차지했습니다. [2. 보안 기능] 영역에서 신규 추가된 항목은 ‘10. 부적절한 전자서명 확인’, ‘11. 부적절한 인증서 유효성 검증’ 2개인데요. 기존 ‘중요정보 평문저장’, ‘중요정보 평문전송’ 항목이 통합돼 ‘5. 암호화되지 않은 중요정보’ 항목이 됐고, 기존 ‘하드코드된 패스워드’, ‘하드코드된 암호화 키’ 항목이 통합되어 ‘6. 하드코드된 중요정보’ 항목이 됐습니다. ‘10. 부적절한 전자서명 확인’ 과 ‘11. 부적절한 인증서 유효성 검증’ 항목은 전자서명법 개정으로 간편인증과 같은 민간 인증사업자의 다양한 전자서명인증서비스가 활성화되며, 이에 따라 발생할 수 있는 위험을 줄이고자 추가된 항목으로 보입니다. 전자서명 및 인증서에 대한 유효성 검증이 적절하지 않아 발생하는 보안 약점입니다. [3. 시간 및 상태] 영역은 기존 소프트웨어 개발 보안 항목과 변동된 점이 없으며, [4. 에러처리] 영역의 ‘오류 메시지 정보 노출’ 항목이 기존 [6. 캡슐화] 영역의 ‘시스템 데이터 정보 노출’ 항목과 통합됐습니다. [5. 코드오류] 영역에서는 ‘5. 신뢰할 수 없는 데이터의 역직렬화’ 항목이 새롭게 추가됐습니다. ‘5. 신뢰할 수 없는 데이터의 역직렬화’ 항목은 직렬화된 데이터를 원래 객체(Object)로 복원할 때 적절한 검증 없이 수행해 발생하는 보안 약점으로, OWASP TOP 10 (2017)...