Риски и меры предосторожности при использовании библиотек в построении бизнес-систем

В современном мире, при создании бизнес-систем, компонент системы, известный как “библиотека”, становится необходимым. Однако, использование библиотеки также связано с рисками. Безрассудное использование может привести к проблемам, а в худшем случае – даже к серьезным последствиям, таким как утечка информации. В этой статье мы обсудим риски, связанные с использованием библиотеки, и способы их предотвращения.

Что такое библиотека

При создании бизнес-системы, системные компании редко создают все необходимые программы самостоятельно. Вместо этого они обычно создают основу с помощью “готовых компонентов программного обеспечения”, а недостающие части создают самостоятельно. Эти готовые компоненты программного обеспечения называются “библиотеками”. Общие функции обычно разрабатываются с использованием библиотек. Под общими функциями подразумеваются такие функции, как “вход в систему” или “получение данных из базы данных”, которые востребованы в любой отрасли и в любой стране. Для таких востребованных функций существуют соответствующие библиотеки. С другой стороны, для функций, которые не являются общими, таких как удовлетворение уникальных требований клиента, готовые библиотеки не существуют, поэтому системные компании должны создавать их самостоятельно.

Кроме того, есть слово “фреймворк”, которое имеет схожее значение с библиотекой. Также есть слово OSS (открытое программное обеспечение). В контексте бизнес-системы, OSS – это компоненты системы, которые являются тем же, что и библиотеки, о которых говорится в этой статье, но это слово может быть более знакомым. Однако в этой статье мы будем использовать слово “библиотека”.

Преимущества библиотек: быстрота и безопасность

Есть две причины, по которым IT-компании предпочитают использовать библиотеки, а не разрабатывать системы самостоятельно.

• Создание системы с использованием библиотеки происходит быстрее
• Безопасность системы, созданной с использованием библиотеки, выше

Быстрота создания системы с использованием готовых решений – это очевидное преимущество. Однако, большим преимуществом является и повышенная безопасность. Почему это так? Потому что известные библиотеки разрабатываются, проверяются и используются в производственной среде лучшими инженерами и компаниями по всему миру. Это означает, что они защищены от известных методов атаки, и в случае обнаружения новых методов атаки, можно ожидать быстрого обновления. Напротив, если вы пытаетесь создать систему самостоятельно, без использования библиотек, вам, возможно, придется включить в процесс отдельный обзор экспертов по безопасности, что может занять дополнительное время. В этом случае, улучшение безопасности может привести к увеличению затрат. Исходя из этих обстоятельств, если вы хотите разработать систему быстрее и безопаснее, использование библиотек становится важным.

Недостатки библиотек

Использование библиотек позволяет быстро и безопасно создавать системы, что приносит большую выгоду как клиентам, так и компаниям-разработчикам систем. Однако использование библиотек также связано с определенными затратами. Кроме того, существует дилемма: если не обновлять библиотеку, возможно появление “уязвимостей”, а при обновлении система может перестать работать.

Если не обновлять, появляются уязвимости

Преступники, которые планируют украсть личную информацию, информацию о кредитных картах или коммерческую тайну, ежедневно ищут уязвимости в безопасности библиотек (и всего программного обеспечения). Эти недостатки в безопасности в IT-терминологии называются “уязвимостями”. Есть много примеров, когда были использованы уязвимости, скрытые в используемых библиотеках, и был нанесен ущерб. Например, был случай, когда примерно 200 000 клиентских данных были утечены из-за атаки на уязвимость библиотеки Struts2, использованной на сайте опросов Министерства земледелия, инфраструктуры, транспорта и туризма, и случай, когда считается, что возможна утечка информации о 32 187 кредитных картах с сайта продажи билетов, который также использовал Struts2. Возможно, уязвимости библиотеки, которые были неизвестны на момент поставки системы, могут быть обнаружены позже.

Обновление сопровождается риском остановки системы

На практике бывают случаи, когда обновление невозможно, несмотря на наличие уязвимостей. Это связано с риском временного прекращения работы системы при обновлении. Библиотеки не являются программами, написанными компаниями-разработчиками систем, поэтому полностью понять их содержание в реальности сложно. Поэтому риск возникновения непредвиденных проблем в системе при обновлении и временного прекращения работы системы невозможно полностью исключить. Клиенты могут возмущаться, если не понимают содержание поставленной системы. Однако факт в том, что библиотеки, используемые в современных системах, по качеству и количеству превышают то, с чем может справиться одна компания-разработчик систем. Например, есть библиотека “React”, которая очень популярна среди библиотек для создания пользовательского интерфейса. Эта библиотека является очень продвинутой в плане качества, так как ее создали инженеры Facebook, а по количеству она насчитывает 195 486 строк кода (※1).

Случаи, когда уязвимости становились предметом судебных разбирательств

Возникает вопрос о том, кто несет ответственность, если ущерб был вызван уязвимостями, связанными с библиотекой. В этом контексте можно обратиться к решению Токийского окружного суда от 23 января 2014 года (Heisei 26). Истец поручил системной компании, являющейся ответчиком, разработку системы продаж. Однако после запуска системы из-за ее уязвимости были утечены данные кредитных карт конечных пользователей, и истец понес ущерб в размере примерно 32 миллионов иен из-за извинений и расследований, что привело к спору. В контракте, заключенном между истцом и ответчиком, было положение об освобождении от ответственности, согласно которому в случае возникновения ущерба по вине ответчика, сумма компенсации ограничивается суммой контракта. Вопросом стало, можно ли применить это положение об освобождении от ответственности. Решение суда состояло в том, что у ответчика была серьезная халатность, и в случае серьезной халатности положение об освобождении от ответственности не может быть применено, и ответчику было приказано выплатить компенсацию, превышающую сумму контракта.

Ответчик, как компания, занимающаяся разработкой систем обработки информации, созданием веб-сайтов, разработкой бизнес-систем и т.д., используя специализированные знания о программировании, предоставил веб-приложение в рамках своего бизнеса, и истец заключил контракт на систему, доверяя этим специализированным знаниям. Следовательно, можно считать, что степень должной осторожности, которую следует проявлять ответчику, довольно высока. Как уже упоминалось, если не были приняты меры против SQL-инъекций, третьи лица могут провести атаку SQL-инъекцией, что может привести к утечке личной информации из базы данных. Это можно было предвидеть ответчику. Кроме того, учитывая, что Министерство экономики, торговли и промышленности и IPA указывали на атаку SQL-инъекцией как на типичный метод атаки на веб-приложения и предупреждали об этом, можно сказать, что было легко предвидеть, что такая ситуация может возникнуть. Кроме того, использование механизма привязки или процесса экранирования могло предотвратить утечку данных, и нет доказательств того, что применение технических мер для предотвращения этого потребовало бы больших усилий или затрат, поэтому можно сказать, что было легко предотвратить утечку данных. Таким образом, можно сказать, что у ответчика была серьезная халатность.

Решение Токийского окружного суда от 23 января 2014 года

Ниже приведено описание документа Фонда по информации о программном обеспечении, которое интерпретирует этот прецедент в контексте уязвимостей библиотеки.

Если предположить, что мы следуем логике этого прецедента, то даже если ущерб пользователю был вызван дефектами OSS (такими как уязвимости), если можно признать, что поставщик умышленно или по грубой небрежности не принял мер против уязвимостей, то, как и в данном случае, применение положения об освобождении от ответственности (ограничение ответственности) может быть ограничено, и вероятность того, что можно будет получить эффект освобождения от ответственности, высока. Однако, если атака произошла сразу после публикации информации о мерах против уязвимостей OSS, то возможность легко предотвратить результат может быть отрицательной, и возможность признания грубой небрежности может быть достаточно высокой.

Сборник вопросов и ответов о правовых проблемах использования OSS в эпоху IoT [PDF][ja] (стр. 84)

Таким образом, даже если уязвимость связана с библиотекой, если она является известной уязвимостью и можно легко предвидеть атаку, вероятность того, что системная компания будет считаться ответственной, высока.

Какие более реалистичные меры против уязвимостей?

Если утечка информации произошла из-за умышленных действий или грубой халатности IT-компании, юридически возможно получить компенсацию через судебный процесс. Однако с практической точки зрения, важно предотвратить утечку информации в первую очередь. Даже если вы получите компенсацию через суд, невозможно восстановить доверие конечных пользователей, потерянное из-за утечки информации. В этом контексте следующие два пункта являются важными:

1. Заключение контракта на обслуживание, включая обновление библиотек
2. Диагностика уязвимостей

Заключение контракта на обслуживание, включая обновление библиотек

В контрактах на разработку бизнес-систем есть два варианта: когда заказчик поручает только разработку и когда он поручает и обслуживание. Если в вашей компании нет специалистов, способных обслуживать систему, то целесообразно заключить контракт на обслуживание. В контракте можно предусмотреть, что IT-компания будет заниматься мерами против уязвимостей, включая обновление библиотек, и ясно определить обязанности IT-компании и обязанности клиента по оплате. Это поможет предотвратить проблемы. В то же время, клиент должен быть готов нести достаточные затраты на услуги специалиста.

Диагностика уязвимостей

Объем данных, обрабатываемых системой, и требования к пользовательскому интерфейсу растут каждый день, в то время как количество новых уязвимостей продолжает увеличиваться. Поэтому IT-компании сложно полностью предотвратить появление уязвимостей. В этом контексте диагностика уязвимостей становится необходимой. Согласно IPA (Японская ассоциация информационной безопасности), более 50% всех компаний и 80% крупных компаний проводят диагностику уязвимостей.

Диагностика уязвимостей варьируется от бесплатных инструментов до дорогостоящих ручных проверок. В частности, если вы работаете с информацией, утечка которой может быть критической, то обязательно нужно нанять специалистов для проведения диагностики уязвимостей и выделить достаточные средства на это. Кроме того, уязвимости обнаруживаются каждый день, поэтому важно проводить диагностику уязвимостей[ja] (P15) не только при поставке, но и после поставки на регулярной основе.

Заключение

В этой статье мы рассмотрели риски, связанные с использованием библиотек, и способы их устранения. Библиотеки очень удобны, но они также несут риски, такие как возникновение уязвимостей и утечка информации, если их не обновлять. С юридической точки зрения, если у компании-разработчика системы есть серьезная халатность, можно ожидать компенсации за утечку информации. Однако на практике важнее всего предотвратить утечку информации. Для этого следует договориться о времени на обновление библиотеки и диагностику уязвимостей. Если вы не используете библиотеки, почти невозможно достичь необходимого уровня сроков и функциональности. Чтобы избежать проблем и воспользоваться преимуществами библиотек, необходимо согласовать с компанией-разработчиком системы стоимость обновления и меры по борьбе с уязвимостями. Чтобы утечка информации не нанесла смертельный удар по вашему бизнесу, важно уделять достаточное внимание не только таким аспектам, как функциональность, макет экрана и цена, но и безопасности с момента заключения договора.