Вступление

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

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

Например, атака типа «отказ в обслуживании» (DoS) может отключить вашу службу, перегрузив трафик, который могут принимать ваши серверы. На практике эти атаки распространяются (Distributed DoS, или сокращенно DDoS) по большой сети злоумышленников, что еще больше затрудняет их отслеживание.

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

Этим атакам противодействуют с помощью фильтрации и выявления недействительных соединений и отказа им в доступе к службе.

Другой распространенной атакой является атака Man-in-the-middle (MitM), когда злоумышленник действует как посредник между данными, передаваемыми между клиентом (пользователем) и вашими серверами.

Существует несколько типов атак MitM, таких как ARP Spoofing, IP Spoofing и DNS Spoofing. Кроме того, они могут обнюхивать отправляемые данные, захватить сеанс и взять его под контроль или даже внедрить пакеты, чтобы скомпрометировать исходный пакет данных.

Эти данные могут быть тривиальными, но они также могут быть очень конфиденциальными - например, данные кредитной карты или личная информация.

Этим атакам противостоит адекватное шифрование передаваемых данных. Даже если их собирает посредник, они не могут понять этого. Кроме того, также помогает использование безопасных каналов, таких как HTTPS поверх HTTP.

Службы, управляемые базой данных, более подвержены атакам с использованием SQL-инъекций , когда нежелательный пользователь получает привилегии в вашей базе данных. Достаточно иметь самые основные привилегии базы данных, чтобы иметь возможность извлекать достаточно информации, чтобы вызвать хаос, в зависимости от того, насколько конфиденциальны данные.

Эти атаки становятся возможными даже при малейшем недосмотре в дизайне и архитектуре приложения, а также при отсутствии проверок запросов в серверной части.

Межсайтовый скриптинг (XSS), атаки с перехватом, атаки вредоносного ПО , фишинг , DNS-туннелирование - существует множество хорошо известных атак, которым может подвергнуться ваше приложение. И снова неизбежно испытать хотя бы один.

При этом не следует забывать о целостности данных и безопасности приложений от начала до конца. Сосредоточение внимания на управлении рисками является важной частью обеспечения безопасности и удовлетворенности клиентов. Вам и вашей команде решать, каким атакам будет подвержено ваше приложение и какие меры защиты вы будете применять.

Вот как вы можете использовать Risk Management and Mitigation, чтобы повысить надежность вашего веб-приложения.

Начните с оценки рисков

Первым шагом к достижению эффективного управления рисками является создание списка рисков, с которыми сталкивается ваше веб-приложение.

Если ваше приложение передает конфиденциальную информацию между клиентами и серверами - ожидайте атаки MitM. Если ваше приложение отправляет много писем с вложениями - ожидайте фишинг-атаки. Если ваше приложение обрабатывает транзакции, зависящие от времени, например брокеры фондового рынка, DDoS-атака может перевернуть все с ног на голову.

Затем вам нужно будет количественно оценить риски, с которыми сталкивается приложение. Количественная оценка позволяет легко сравнивать риски, определять наиболее важные из них и выбирать подходящие меры контроля рисков.

При количественной оценке риска вам нужно будет оценить стоимость вашего актива, серьезность риска и вероятность возникновения риска. В большинстве случаев достаточно шкалы от 1 до 10, где 10 соответствует наибольшему весу.

Чтобы количественно оценить возможный риск, просто используйте это уравнение:

$$
R = V * I * L
$

Где: R = риск атаки, V = стоимость веб-приложения или актива, I = влияние риска и L = вероятность возникновения риска.

Например, возьмем сервер с рейтингом 10 . Если влияние его отключения из-за DDoS-атаки равно 10 и вероятность того, что это произойдет , также равна 10 , риск рассчитывается как:

$$
R = 10 * 10 * 10
$

Это самый высокий риск, которому может подвергаться ваш бизнес ( 1000 ). Вы не должны упускать из виду это. Обратитесь к слону в комнате и сконцентрируйте ресурсы и знания на этом вопросе, чтобы снизить вероятность его оживления. Подобные риски всегда должны иметь наивысший приоритет.

Напротив, представьте, что ваш бизнес основан на обслуживании контента, такого как блог или информативный веб-сайт. Единственные данные, которые передаются между вашими пользователями и приложением, - это простые HTTP-запросы к серверу для возврата запрошенного содержимого.

Атака, подобная MitM, не предоставит злоумышленнику никакой важной информации, кроме IP-адреса пользователя, что в подавляющем большинстве случаев не так уж и полезно.

Таким образом, значение сервера равно 10 (это неотъемлемая часть предоставления данных пользователям), но влияние атаки MitM не так уж и велико. Скажем, мы ставим ему 5 . Поскольку такая атака не приносит злоумышленнику особой пользы, вероятность того, что она произойдет, также не слишком высока, поэтому давайте присвоим ей 5 .

Таким образом, риск этой атаки будет:

$$
R = 10 * 5 * 5
$

Величина риска этой атаки ( 250 ) значительно ниже, чем вышеупомянутой атаки.

Выбор вариантов снижения риска

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

Риски, которые могут быть переданы другому лицу или организации, рассмотрите возможность их передачи. Например, покупка киберстраховки может помочь снизить риски многих типов стандартных атак. Для этого нет необходимости внедрять решения внутри компании, если у вас нет времени или ресурсов.

Конечно, определенное количество внутренних решений общих проблем не должно быть трудным для реализации - например, шифрование передаваемых данных, использование безопасных носителей передачи, хеширование паролей и т. Д.

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

Решения рисков веб-разработки

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

В интересах затрат на разработку и времени выхода на рынок команды разработчиков иногда вынуждены оставлять приложения с некоторыми лазейками, которые могут привести к проблемам в будущем. Цель состоит в том, чтобы позже вернуться к таким проблемам и решить их, как только приложение уже появится на рынке.

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

Чем больше откладывается решение этих проблем, тем больше будет вложений для их исправления. Кроме того, ваша команда, скорее всего, будет более склонна продолжать опираться на то, что существует, вместо того, чтобы разбирать это, чтобы исправить лазейки. Это может легко привести к тому, что откладывание будет отложено во имя затрат на разработку и соблюдения сроков, что в конечном итоге приведет к нестабильным и ненадежным приложениям.

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

«Если вы думаете, что хорошая архитектура стоит дорого, попробуйте дешевую архитектуру». - Брайан Фут

Не усложняйте свое приложение

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

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

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

Шифруйте свои данные и трафик

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

Убедитесь, что вы зашифровали как веб-трафик, так и данные, хранящиеся на вашем сервере, чтобы ограничить ущерб, который может быть нанесен, когда ваше приложение подвергается риску.

Сосредоточьтесь на тестировании и обслуживании

Любое решение по обработке рисков, которое вы выберете, должно быть проверено на его эффективность. Установка правильных ключевых показателей эффективности (KPI) поможет вам оценить, достаточно ли они эффективны.

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

Управление рисками должно быть неотъемлемой частью разработки веб-приложений, а не второстепенным. Поскольку он играет центральную роль в разработке вашего приложения, становится легко устранять основные проблемы в их корне задолго до того, как они могут превратиться в угрозу.

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

об авторе

Джордан МакЭвой - вице-президент по маркетингу Reciprocity Labs и руководит стратегией выхода компании на рынок и ее реализацией. До прихода в Reciprocity г-н МакЭвой занимал руководящие должности в Fundbox, компании Forbes Next Billion Dollar, и Intuit, после приобретения ими SaaS-решения для маркетинга и коммуникаций Demandforce.