업무 시스템 구축에서 라이브러리 사용에 따른 위험과 대책

현대에 있어서, 업무 시스템 구축에서는 ‘라이브러리’라는 시스템의 부품이 필수적이게 되었습니다. 그러나, 라이브러리의 사용에는 위험성도 있습니다. 위험성을 무시하고 사용하는 것은 문제를 초래하며, 최악의 경우 정보 유출 등 심각한 피해를 입을 위험까지 있습니다. 본 글에서는 라이브러리의 사용에 숨어 있는 위험성과 그에 대한 대책에 대해 설명하겠습니다.

라이브러리란 무엇인가

업무 시스템을 구축할 때, 시스템 회사가 필요한 프로그램을 모두 자체적으로 제작하는 경우는 거의 없습니다. 대신, ‘기성의 소프트웨어 부품’으로 기초를 만들고, 부족한 부분을 자체적으로 제작하는 형태를 취하는 것이 일반적입니다. 이러한 기성의 소프트웨어 부품을 ‘라이브러리’라고 부릅니다. 범용적인 기능은 라이브러리를 활용하여 개발하는 것이 일반적입니다. 범용적이라 함은 ‘로그인 기능’이나 ‘데이터베이스에서 데이터를 가져오는 기능’과 같이, 어떤 업계, 어떤 나라의 시스템에서도 수요가 높은 기능을 말합니다. 이러한 수요가 높은 기능에는 대응하는 라이브러리가 존재합니다. 반면, 고객만의 요구를 충족시키는 등 범용적이지 않은 기능에는 기성의 라이브러리가 존재하지 않으므로 시스템 회사가 자체적으로 제작하게 됩니다.

참고로, 라이브러리와 비슷한 의미로 프레임워크라는 단어도 있습니다. 또한, OSS(오픈소스 소프트웨어)라는 단어도 있습니다. 업무 시스템의 맥락에서 말하는 OSS는 시스템의 부품이며, 본 글에서 말하는 라이브러리와 같은 것이지만, 더 익숙한 단어일 수도 있습니다. 그러나 본 글에서는 라이브러리라는 단어로 통일합니다.

라이브러리의 장점: 빠르고 안전하다

시스템 회사가 자체 제작보다 라이브러리 사용을 우선하는 이유는 두 가지입니다.

• 자체 제작보다 빠르게 만들 수 있다
• 자체 제작보다 보안이 높아진다

빠르게 만들 수 있다는 것은 이미 제작된 제품을 사용하는 것이 당연하지만, 보안 측면에서도 우수하다는 것이 큰 특징입니다. 이유는 무엇일까요? 유명한 라이브러리는 전 세계의 우수한 엔지니어와 기업이 개발, 검증, 실제 환경에서의 사용을 계속하고 있기 때문에, 이미 알려진 공격 방법에 대한 대책이 마련되어 있고, 새로운 공격 방법이 발견되었을 경우에도 빠른 업데이트가 가능하기 때문입니다. 반대로, 라이브러리를 사용하지 않고, 자체 제작하려고 할 경우, 보안 측면에서의 문제를 검토하기 위해 별도의 전문가 리뷰를 거치는 등의 번거로움이 발생할 수도 있습니다. 그럴 경우, 결과적으로 보안을 향상시키려면 비용이 발생할 수도 있습니다. 이러한 여러 상황으로 인해, 더 빠르고, 더 안전하게 시스템 개발을 진행하려면, 라이브러리의 사용이 중요해지는 것입니다.

라이브러리의 단점이란

라이브러리의 사용은 빠르고 안전하게 시스템을 구축할 수 있어 고객과 시스템 회사 양쪽에 큰 이점이 있습니다. 그러나 반면에, 라이브러리의 사용에는 일정한 비용이 필요합니다. 또한, 업데이트를 하지 않을 경우 ‘취약점’이 섞일 가능성이 있고, 업데이트를 할 경우 시스템이 작동하지 않을 가능성이 있는 딜레마도 존재합니다.

업데이트를 하지 않으면 취약점이 존재한다

개인 정보나 신용카드 정보, 기업 비밀을 도용하려는 범죄자들은 매일 라이브러리(포함된 모든 소프트웨어)의 보안 결함을 찾고 있습니다. 이러한 보안 결함은 IT 용어로 ‘취약점’이라고 합니다. 사용한 라이브러리에 숨어있는 취약점을 공격받아 피해를 입은 사례는 많습니다. 예를 들어, 일본 국토교통성의 설문조사 사이트에서 사용하던 Struts2라는 라이브러리의 취약점을 공격받아 약 20만 건의 고객 정보가 유출된 사례, 마찬가지로 Struts2를 사용하는 티켓 판매 사이트에서 신용카드 정보 3만 2187건이 유출될 가능성이 있는 사례가 있습니다. 시스템의 납품 시점에서는 알 수 없었던 라이브러리의 취약점이 후에 발견되는 경우도 있습니다.

업데이트에는 시스템 중단 위험이 동반된다

현장에서는 취약점이 있음에도 불구하고 업데이트를 할 수 없는 경우가 있습니다. 그 이유는 업데이트로 인해 시스템이 일시적으로 작동하지 않는 위험이 있기 때문입니다. 라이브러리는 시스템 회사가 작성한 프로그램이 아니므로 내용을 모두 파악하는 것은 현실적으로 어렵습니다. 따라서, 업데이트로 인해 시스템에 예상치 못한 문제가 발생하고, 시스템이 일시적으로 작동하지 않는 위험은 어쩔 수 없이 제거할 수 없습니다. 고객으로서는, 납품한 시스템의 내용을 파악하지 못하고 있는 것에 대해 시스템 회사에 분노를 느낄 수도 있습니다. 그러나, 현대의 시스템에서 사용하는 라이브러리는 품질과 양 모두를 한 시스템 회사에서 처리할 수 있는 것이 아닌 것도 사실입니다. 예를 들어, 위탁자 인터페이스 구축을 위한 라이브러리 중에서 가장 인기 있는 ‘React’라는 라이브러리가 있습니다. 이 라이브러리는 품질 면에서는 Facebook의 엔지니어가 만든 매우 고급스러운 것이며, 양 면에서는 코드 줄 수로 195,486줄(※1)이라는 방대한 양입니다.

취약점이 재판이 된 사례

라이브러리에서 발생하는 취약점으로 인해 피해가 발생한 경우, 책임은 누가 지는지에 대한 문제가 있습니다. 이를 참고로 할 수 있는 것이 도쿄지방법원 2014년(헤이세이 26년) 1월 23일 판결입니다. 원고는 피고인인 시스템 회사에 판매 시스템 구축을 위탁했습니다. 그러나 시스템이 작동한 후, 시스템의 취약점으로 인해 엔드 유저의 신용카드 정보가 유출되어, 원고는 사과와 조사 등으로 약 3,200만 엔의 피해를 입어 분쟁이 발생했습니다. 원고와 피고가 체결한 계약에는, 피고의 과실로 인해 손해가 발생한 경우, 손해배상액을 계약금액까지로 하는 면책조항이 있었습니다. 이 면책조항을 적용할 수 있는지 여부가 논점이었습니다. 판결은, 피고에게 중과실이 있고, 중과실이 있는 경우 면책조항은 적용할 수 없다고 판단하여 피고에게 계약금액을 초과한 배상을 명령했습니다.

피고는 정보 처리 시스템의 기획, 홈페이지 제작, 업무 시스템 개발 등을 수행하는 회사로서, 프로그램에 관한 전문적 지식을 활용한 사업을 전개하고, 그 사업의 일환으로 이 웹 애플리케이션을 제공하고 있으며, 원고도 그 전문적 지식을 신뢰하여 이 시스템 발주 계약을 체결한 것으로 인정할 수 있으며, 피고에게 요구되는 주의 의무의 정도는 상당히 높은 것으로 인정됩니다. 따라서, SQL 인젝션 대책이 없다면, 제3자가 SQL 인젝션 공격을 수행함으로써 이 데이터베이스에서 개인 정보가 유출될 상황이 발생할 수 있다는 것은 피고에게 예견 가능했으며, 또한, 경제산업성과 IPA가 웹 애플리케이션에 대한 대표적인 공격 방법으로 SQL 인젝션 공격을 언급하고, (중략) 주의를 환기하고 있었던 것을 고려하면, 그 상황이 발생할 수 있다는 것을 예견하는 것은 쉬웠다고 할 수 있습니다. 또한, 바인드 메커니즘의 사용 또는 이스케이프 처리를 수행함으로써, 이 유출이라는 결과를 피할 수 있었던 것으로, (중략: 피하기 위한 처리의 기술적 대책의 의미)를 수행하는 데 큰 노력이나 비용이 들 것이라는 증거는 없으며, 이 유출이라는 결과를 피하는 것은 쉬웠다고 할 수 있습니다.
그러므로, 피고에게는 중과실이 인정될 수 있다고 할 것입니다.

도쿄지방법원 2014년(헤이세이 26년) 1월 23일

이 판례를 라이브러리의 취약점에 대한 맥락에서 해석한 것이 아래 일반 재단법인 소프트웨어 정보 센터의 자료의 기술입니다.

이 판례의 생각을 전제로 하면, 가령 OSS의 결함(취약점 등)으로 인해 위탁자에게 손해가 발생한 경우에도, 벤더가 취약점 대응을 게을리 한 것에 대해 고의·중과실이 인정되는 경우, 이 사례와 마찬가지로, 면책조항(책임 제한 조항)의 적용이 제한되고, 면책 효과를 얻을 수 없을 가능성이 높다고 말할 수 있습니다. 그러나, OSS의 취약점 대책 정보가 공개된 직후 공격을 받은 경우에는, 결과 회피의 용이성이 부정되는 등, 중과실까지 인정되지 않을 가능성도 충분히 있습니다.

IoT 시대에 있어서 OSS의 이용과 법적 여러 문제 Q&A집[PDF][ja] (84페이지)

이와 같이, 라이브러리에서 발생하는 취약점이라도 그것이 이미 알려진 취약점이며 공격을 예견하는 것이 용이하다고 인정되는 경우에는, 시스템 회사의 책임으로 간주될 가능성이 높다고 생각됩니다.

더 현실적인 취약점 대응책은 무엇인가

시스템 회사의 고의나 중대한 과실로 인해 정보 유출이 발생한 경우, 법적으로는 소송을 통해 보상을 받을 수 있다고 예상됩니다. 그러나 실무적인 측면에서 보면, 정보 유출을 일으키지 않는 것이 가장 중요합니다. 소송을 통해 보상을 받았다 하더라도, 정보 유출로 잃어버린 엔드 유저의 신뢰는 회복할 수 없기 때문입니다. 그러므로 다음의 두 가지가 중요합니다.

1. 라이브러리 업데이트를 포함한 유지보수 계약 체결
2. 취약점 진단

라이브러리 업데이트를 포함한 유지보수 계약 체결

업무 시스템 구축 계약에는 개발만을 위탁하는 경우와 유지보수까지 위탁하는 경우가 있습니다. 만약 회사에 유지보수가 가능한 전문가가 없다면, 유지보수 계약을 체결하는 것이 적절합니다. 계약에서는 라이브러리의 업데이트를 포함한 취약점 대응책을 시스템 회사에 요청하고, 시스템 회사의 응답 의무와 그에 따른 고객의 지불 의무를 명확히 하여 문제를 예방할 수 있습니다. 시스템 회사에 전문가로서의 대응을 의무화하는 한편, 고객도 전문가에게 요청하는데 충분한 비용을 부담하는 계약이 필요하다고 할 수 있습니다.

취약점 진단

시스템이 다루는 데이터 양이나 UI에 대한 요구사항이 날로 증가하는 반면, 새롭게 발견되는 취약점의 수가 계속해서 증가하고 있습니다. 따라서 시스템 회사만으로는 취약점의 혼입을 완전히 막는 것이 어려운 현실이 있습니다. 이때 필요한 것이 취약점 진단입니다. IPA에 따르면, 전체적으로 50% 이상, 대기업 등에서는 80%의 사업자가 취약점 진단을 실시하고 있습니다.

취약점 진단은 무료 도구부터 고가의 수동 진단까지 다양합니다. 특히 유출되면 치명적인 정보 등을 다루는 경우, 취약점 진단을 전문으로 하는 사업자에게 위탁하고 충분한 비용을 들여 대응하는 것이 필수적이라고 할 수 있습니다. 또한 취약점은 매일 발견되므로, 납품 시뿐만 아니라 납품 후에도 지속적으로 취약점 진단[ja] (P15)을 실시하는 것이 중요하다고 할 수 있습니다.

요약

본 글에서는 라이브러리 사용에 따른 위험과 그에 대한 대처 방법에 대해 설명하였습니다. 라이브러리는 매우 편리하지만, 업데이트를 하지 않으면 취약점이 발생하고 정보 유출 등의 피해가 발생하는 등의 위험이 있습니다. 법적으로는 시스템 회사의 중대한 과실이 있는 경우 정보 유출에 대한 보상을 받을 수 있는 가능성이 있지만, 실무적으로는 정보 유출이 발생하지 않도록 대책을 세우는 것이 중요합니다. 이를 위해 라이브러리의 업데이트 작업 시간이나 취약점 진단에 대해 계약 시 합의해 두어야 합니다. 라이브러리를 사용하지 않는 경우, 납기와 기능 모두 필요한 수준에 도달하는 것은 거의 불가능합니다. 문제를 피하면서 라이브러리의 장점을 누리려면, 시스템 회사와의 사이에서 업데이트 비용이나 취약점에 대한 대책에 대해 합의를 이루는 것이 필요하다고 생각됩니다. 정보 유출로 인해 비즈니스에 치명적인 타격을 입지 않기 위해서도, 기능이나 화면 레이아웃, 가격 등의 요소뿐만 아니라 보안에 대해서도 계약 시 충분한 주의를 기울이는 것이 중요하다고 생각됩니다.