MONOLITH LAW OFFICE+81-3-6262-3248Ngày làm việc 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

Rủi ro và biện pháp phòng ngừa khi sử dụng thư viện trong việc xây dựng hệ thống kinh doanh

IT

Rủi ro và biện pháp phòng ngừa khi sử dụng thư viện trong việc xây dựng hệ thống kinh doanh

Trong thời đại hiện đại, việc xây dựng hệ thống kinh doanh đòi hỏi phần tử hệ thống được gọi là “thư viện”. Tuy nhiên, việc sử dụng thư viện cũng tiềm ẩn rủi ro. Việc sử dụng mà không chú ý đến rủi ro có thể gây ra rắc rối, và trong trường hợp xấu nhất, có thể dẫn đến hậu quả nghiêm trọng như rò rỉ thông tin. Bài viết này sẽ giải thích về rủi ro tiềm ẩn khi sử dụng thư viện và các biện pháp phòng ngừa.

Thư viện là gì?

Khi xây dựng hệ thống kinh doanh, hầu như không có công ty hệ thống nào tự tạo ra tất cả các chương trình cần thiết. Thay vào đó, họ thường xây dựng nền tảng bằng “các bộ phận phần mềm sẵn có” và tạo ra các phần còn thiếu trong công ty. Các bộ phận phần mềm sẵn có này được gọi là “thư viện”. Việc sử dụng thư viện để phát triển các chức năng phổ biến là điều thông thường. Các chức năng phổ biến bao gồm “chức năng đăng nhập” hoặc “chức năng lấy dữ liệu từ cơ sở dữ liệu”, đây là những chức năng có nhu cầu cao trong mọi ngành nghề, mọi hệ thống của mọi quốc gia. Các chức năng có nhu cầu cao như vậy đều có thư viện tương ứng. Ngược lại, các chức năng không phổ biến, như việc đáp ứng yêu cầu độc đáo của khách hàng, không có thư viện sẵn có nên công ty hệ thống sẽ phải tự tạo ra.

Xin lưu ý, cũng có từ “framework” có nghĩa tương tự như thư viện. Ngoài ra, cũng có từ OSS (Phần mềm nguồn mở). Trong ngữ cảnh của hệ thống kinh doanh, OSS là một bộ phận của hệ thống và cũng giống như thư viện mà chúng tôi đề cập trong bài viết này, nhưng có thể là từ mà bạn quen thuộc hơn. Tuy nhiên, trong bài viết này, chúng tôi sẽ sử dụng từ “thư viện” để thống nhất.

Ưu điểm của thư viện: Nhanh và an toàn

Có hai lý do mà các công ty hệ thống ưu tiên sử dụng thư viện hơn là tự tạo.

  • Tạo nhanh hơn tự làm
  • An ninh cao hơn tự làm

Việc tạo nhanh hơn khi sử dụng sản phẩm sẵn có là điều hiển nhiên, nhưng đặc điểm lớn là nó cũng vượt trội về mặt bảo mật. Điều này là do những thư viện nổi tiếng được các kỹ sư và doanh nghiệp xuất sắc trên toàn thế giới tiếp tục phát triển, kiểm tra và sử dụng trong môi trường sản xuất, vì vậy các biện pháp phòng chống các phương pháp tấn công đã biết đã được thực hiện, và cập nhật nhanh chóng có thể được kỳ vọng ngay cả khi phát hiện ra phương pháp tấn công mới. Ngược lại, nếu bạn cố gắng tự tạo mà không sử dụng thư viện, có thể sẽ phải mất công để thảo luận về các vấn đề bảo mật, như việc đưa vào xem xét của chuyên gia. Trong trường hợp đó, có thể sẽ phải tốn chi phí để cải thiện bảo mật. Do những lý do như vậy, việc sử dụng thư viện trở nên quan trọng nếu bạn muốn phát triển hệ thống một cách nhanh chóng và an toàn hơn.

Nhược điểm của thư viện

Sử dụng thư viện mang lại lợi ích lớn cho cả khách hàng và công ty hệ thống vì có thể tạo ra hệ thống một cách nhanh chóng và an toàn. Tuy nhiên, việc sử dụng thư viện cũng có một số chi phí nhất định. Hơn nữa, cũng có những mâu thuẫn như việc có thể có “lỗ hổng” nếu không cập nhật, hoặc hệ thống có thể ngừng hoạt động nếu cập nhật.

Nếu không cập nhật, sẽ có lỗ hổng

Các tội phạm nhắm vào việc đánh cắp thông tin cá nhân, thông tin thẻ tín dụng, và bí mật doanh nghiệp đang hàng ngày tìm kiếm những lỗ hổng về bảo mật trong thư viện (bao gồm tất cả phần mềm). Những lỗ hổng bảo mật này được gọi là “lỗ hổng” trong thuật ngữ IT. Có nhiều ví dụ về việc bị tấn công thông qua lỗ hổng trong thư viện đã sử dụng và gây thiệt hại. Ví dụ, có khoảng 200.000 thông tin khách hàng đã bị rò rỉ khi trang web khảo sát của Bộ Giao thông và Xây dựng Nhật Bản (Japanese Ministry of Land, Infrastructure, Transport and Tourism) bị tấn công thông qua lỗ hổng trong thư viện Struts2 mà họ đã sử dụng. Cũng có một ví dụ khác là trang web bán vé sử dụng Struts2 có thể đã để lộ 32.187 thông tin thẻ tín dụng. Cũng có trường hợp lỗ hổng trong thư viện không được biết đến vào thời điểm giao hệ thống, nhưng sau đó được phát hiện.

Cập nhật có rủi ro dừng hệ thống

Trên thực tế, có những trường hợp không thể cập nhật mặc dù có lỗ hổng. Đó là bởi vì có rủi ro hệ thống tạm thời ngừng hoạt động do cập nhật. Thư viện không phải là chương trình mà công ty hệ thống đã viết, vì vậy việc hiểu rõ hoàn toàn nội dung là khó khăn trong thực tế. Do đó, không thể hoàn toàn loại bỏ rủi ro như việc hệ thống tạm thời ngừng hoạt động do lỗi không lường trước xảy ra trong quá trình cập nhật. Khách hàng có thể cảm thấy tức giận với công ty hệ thống nếu họ không hiểu rõ nội dung của hệ thống đã giao. Tuy nhiên, sự thật là có những thư viện được sử dụng trong hệ thống hiện đại mà chất lượng và số lượng đều vượt quá khả năng của một công ty hệ thống bình thường. Ví dụ, có một thư viện có tên “React” rất phổ biến trong việc xây dựng giao diện người dùng. Thư viện này rất cao cấp vì được tạo ra bởi các kỹ sư của Facebook, và về mặt số lượng, nó có 195.486 dòng mã (※1).

(※1) Đo lường tại thời điểm 7:57 AM GMT+9 ngày 23 tháng 6, 2019, dựa trên master tại
https://github.com/facebook/react/commit/39b97e8eb87b2b3b0d938660e1ac12223470fdf5
sử dụng phiên bản cloc 1.82.

Vụ án liên quan đến lỗ hổng đã được đưa ra xét xử

Trách nhiệm bồi thường khi gây thiệt hại do lỗ hổng trong thư viện phần mềm?

Khi gây ra thiệt hại do lỗ hổng xuất phát từ thư viện phần mềm, câu hỏi đặt ra là ai sẽ chịu trách nhiệm. Một ví dụ tham khảo cho vấn đề này là phán quyết của Tòa án quận Tokyo vào ngày 23 tháng 1 năm 2014 (năm Heisei 26). Nguyên đơn đã ủy thác cho bị đơn, một công ty hệ thống, xây dựng hệ thống bán hàng. Tuy nhiên, sau khi hệ thống hoạt động, thông tin thẻ tín dụng của người dùng cuối đã bị rò rỉ do lỗ hổng của hệ thống, và nguyên đơn đã phải chịu thiệt hại khoảng 32 triệu yên do việc xin lỗi và điều tra, dẫn đến tranh chấp. Trong hợp đồng mà nguyên đơn và bị đơn đã ký kết, có điều khoản miễn trừ trách nhiệm nếu thiệt hại xảy ra do lỗi của bị đơn, giới hạn số tiền bồi thường đến mức tiền hợp đồng. Điểm tranh chấp là liệu có thể áp dụng điều khoản miễn trừ trách nhiệm này hay không. Phán quyết cho rằng bị đơn đã có lỗi nặng, và trong trường hợp có lỗi nặng, điều khoản miễn trừ trách nhiệm không thể áp dụng, và đã ra lệnh cho bị đơn bồi thường số tiền vượt quá số tiền hợp đồng.

Bị đơn, là một công ty hoạt động trong lĩnh vực kế hoạch hóa hệ thống xử lý thông tin, sản xuất trang web, phát triển hệ thống kinh doanh, v.v., đã cung cấp ứng dụng web này như một phần của hoạt động kinh doanh của mình bằng cách sử dụng kiến thức chuyên môn về lập trình, và nguyên đơn đã tin tưởng vào kiến thức chuyên môn đó và ký kết hợp đồng đặt hàng hệ thống này. Do đó, mức độ nghĩa vụ chú ý được yêu cầu từ bị đơn được công nhận là tương đối cao. Như đã nêu ở trên, nếu không có biện pháp chống lại cuộc tấn công SQL Injection, có thể xảy ra tình huống mà thông tin cá nhân bị rò rỉ từ cơ sở dữ liệu này do cuộc tấn công SQL Injection của bên thứ ba, và điều này có thể dự đoán được bởi bị đơn. Hơn nữa, Bộ Kinh tế, Thương mại và Công nghiệp và IPA đã nêu cuộc tấn công SQL Injection là một phương pháp tấn công đại diện cho ứng dụng web, và đã cảnh báo (trích dẫn) về điều này, nên dễ dàng dự đoán được rằng tình huống đó có thể xảy ra. Ngoài ra, bằng cách sử dụng cơ chế bind hoặc thực hiện xử lý thoát, kết quả rò rỉ này có thể được tránh, và không có bằng chứng cho thấy việc thực hiện (trích dẫn: biện pháp kỹ thuật để tránh) mất nhiều công sức hoặc chi phí, nên dễ dàng tránh được kết quả rò rỉ này. Vì vậy, nên công nhận rằng bị đơn đã có lỗi nặng.

Phán quyết của Tòa án quận Tokyo ngày 23 tháng 1 năm 2014 (năm Heisei 26)

Mô tả trong tài liệu của Tổ chức phi lợi nhuận Software Information Center đã diễn giải phán quyết này trong bối cảnh lỗ hổng của thư viện phần mềm như sau:

Nếu giả định rằng cách suy nghĩ trong phán quyết này là tiền đề, thậm chí khi thiệt hại xảy ra đối với người dùng do lỗi (lỗ hổng, v.v.) của OSS, nếu nhà cung cấp đã bỏ qua việc xử lý lỗ hổng và lỗi nặng hoặc cố ý được công nhận, giống như trong trường hợp này, việc áp dụng điều khoản miễn trừ trách nhiệm (điều khoản giới hạn trách nhiệm) sẽ bị hạn chế, và có khả năng cao sẽ không thể nhận được hiệu quả miễn trừ. Tuy nhiên, nếu bị tấn công ngay sau khi thông tin về biện pháp đối phó với lỗ hổng của OSS được công bố, có thể phủ nhận khả năng dễ dàng tránh kết quả, và có thể không công nhận lỗi nặng.

Bộ sưu tập Q&A về các vấn đề pháp lý liên quan đến việc sử dụng OSS trong thời đại IoT [PDF][ja] (trang 84)

Như vậy, ngay cả khi là lỗ hổng xuất phát từ thư viện phần mềm, nếu đó là lỗ hổng đã biết và việc dự đoán cuộc tấn công được công nhận là dễ dàng, có khả năng cao sẽ được xem là trách nhiệm của công ty hệ thống.

Biện pháp phòng ngừa lỗ hổng thực tế hơn là gì?

Việc ký kết hợp đồng bảo dưỡng và việc kiểm tra lỗ hổng là chìa khóa cho việc phòng ngừa lỗ hổng.

Nếu rò rỉ thông tin xảy ra do cố ý hoặc sơ suất nghiêm trọng của công ty hệ thống, từ góc độ pháp lý, có thể dự kiến sẽ nhận được bồi thường thông qua kiện tụng. Tuy nhiên, từ góc độ thực tế, điều quan trọng là không để xảy ra rò rỉ từ đầu. Ngay cả khi nhận được bồi thường thông qua kiện tụng, sự tin tưởng từ người dùng cuối mà bạn đã mất do rò rỉ thông tin không thể phục hồi. Vì vậy, hai điều sau đây quan trọng:

  1. Ký kết hợp đồng bảo dưỡng bao gồm cập nhật thư viện
  2. Kiểm tra lỗ hổng

Ký kết hợp đồng bảo dưỡng bao gồm cập nhật thư viện

Trong hợp đồng xây dựng hệ thống kinh doanh, có trường hợp chỉ ủy thác phát triển và trường hợp ủy thác cả bảo dưỡng. Nếu công ty không có chuyên gia có thể bảo dưỡng, việc ký kết hợp đồng bảo dưỡng là phù hợp. Trong hợp đồng, việc yêu cầu công ty hệ thống thực hiện các biện pháp phòng ngừa lỗ hổng bao gồm cập nhật thư viện và rõ ràng hóa nghĩa vụ phản ứng của công ty hệ thống và nghĩa vụ thanh toán của khách hàng có thể ngăn chặn rắc rối. Trong khi buộc công ty hệ thống phải phản ứng như một chuyên gia, khách hàng cũng cần ký kết hợp đồng mà họ phải chịu chi phí đủ để yêu cầu chuyên gia.

Kiểm tra lỗ hổng

Số lượng dữ liệu mà hệ thống xử lý và yêu cầu đối với giao diện người dùng tăng lên hàng ngày, trong khi số lượng lỗ hổng mới được phát hiện tiếp tục tăng. Do đó, chỉ với công ty hệ thống, việc ngăn chặn hoàn toàn việc lẫn lộ hổng là khó khăn. Đó là nơi cần đến việc kiểm tra lỗ hổng. Theo IPA, hơn 50% tổng số, và 80% các doanh nghiệp lớn đang thực hiện kiểm tra lỗ hổng.

Có nhiều loại kiểm tra lỗ hổng, từ các công cụ miễn phí đến kiểm tra thủ công đắt tiền. Đặc biệt, khi xử lý thông tin mà việc rò rỉ có thể gây ra hậu quả nghiêm trọng, việc giao việc kiểm tra lỗ hổng cho các doanh nghiệp chuyên về việc này và chi tiêu đủ chi phí cho các biện pháp phòng ngừa là cần thiết. Ngoài ra, vì lỗ hổng được phát hiện hàng ngày, không chỉ vào thời điểm giao hàng mà còn sau khi giao hàng, việc tiếp tục thực hiện kiểm tra lỗ hổng[ja] (trang 15) là quan trọng.

Tóm tắt

Trong bài viết này, chúng tôi đã giải thích về những rủi ro liên quan đến việc sử dụng thư viện và cách đối phó với chúng. Mặc dù thư viện rất tiện lợi, nhưng nếu không cập nhật, sẽ xuất hiện lỗ hổng dẫn đến rò rỉ thông tin và gây ra thiệt hại. Từ phía pháp lý, nếu công ty hệ thống có lỗi nghiêm trọng, có thể được bồi thường cho việc rò rỉ thông tin. Tuy nhiên, trong thực tế, việc quan trọng là phải có biện pháp để ngăn chặn việc rò rỉ thông tin từ đầu. Để làm được điều này, bạn nên thống nhất trong hợp đồng về thời gian cập nhật thư viện và việc kiểm tra lỗ hổng. Nếu không sử dụng thư viện, việc đạt được cả hai yêu cầu về thời hạn và chức năng gần như là không thể. Để tận hưởng lợi ích của thư viện mà không gặp rắc rối, bạn cần thống nhất với công ty hệ thống về chi phí cập nhật và biện pháp đối phó với lỗ hổng. Để không bị ảnh hưởng nghiêm trọng đến kinh doanh do rò rỉ thông tin, không chỉ cần chú ý đến các yếu tố như chức năng, giao diện và giá cả, mà còn cần chú ý đến an ninh từ thời điểm ký hợp đồng.

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

Quay lại Lên trên