Подсказка: ваш браузер небезопасен!
Зачем заботиться об информационной безопасности?
Не будь этим человеком! Вы знаете, айтишник, который бесцеремонно относится к информационной безопасности и затем становится заголовком.
- Facebook: 50 миллионов пользователей
- ФИФА: 3,4 терабайта данных и 70 миллионов документов
- Google+: 500 000 аккаунтов
- British Airways: 380 тыс. Транзакций
- T-Mobile: 2 миллиона клиентов
- Marriott Hotels: 427 миллионов клиентов
Если мы, как профессионалы, ничему не научились за последнее десятилетие, так это тому, что информационные системы всех видов и размеров подвергаются усиливающимся атакам со стороны случайных хакеров, преступных элементов и национальных государств.
Растет не только количество нарушений, но и связанный с этим денежный ущерб. По мировым оценкам, средняя стоимость устранения утечки данных составляет 3,86 миллиона долларов. Конечно, это средний показатель, и фактические расходы зависят от объема задействованных данных, а также сложности и сложности проникновения в систему безопасности.
Дальнейшая разбивка сметы средней стоимости:
- 148 долларов США за запись
- 40 миллионов долларов за 1 миллион записей
- 350 миллионов долларов за 50 миллионов записей
С чисто эгоистичной точки зрения подумайте о навязчивости, которая возникает в результате усилий по сдерживанию и устранению последствий нарушения. Когда организации обнаруживают, что они пострадали от взлома, возникает менталитет «все готово», привлекаются консультанты по безопасности и правоохранительные органы, высшее руководство уделяет ИТ более пристальное внимание, и продуктивная работа прекращается.
«Если это не весело, значит, вы делаете это неправильно»… Фрэн Таркентон
Безопасность инфраструктуры и безопасность приложений
Большинство программ информационной безопасности сосредоточены на защите основных ИТ-компонентов, включая сети, ПК и серверы, хранилища и центры обработки данных. Сосредоточение внимания на инфраструктуре важно, но это не единственный компонент зрелой программы информационной безопасности.
Безопасность приложений включает в себя множество методов, которые позволяют находить, исправлять и предотвращать эксплуатируемые уязвимости в прикладном программном обеспечении. Эти методы охватывают весь жизненный цикл приложения и включают:
- Проверки кода, проводимые специалистами по безопасности, цель которых - выявить недостатки безопасности, присущие только приложению.
- Аудит безопасности Blackbox на основе использования приложения
- Перед написанием исходного кода проверьте дизайн приложения в рамках модели угроз.
- Использование инструментов автоматического тестирования, специально разработанных для выявления уязвимостей.
- Внедряйте краудсорсинговые программы вознаграждений, чтобы использовать хакеров в белой шляпе для обнаружения и исправления уязвимостей, прежде чем они могут быть использованы.
Наиболее полезные процессы информационной безопасности основаны на концепции многоуровневой безопасности. Многоуровневый подход обеспечивает эшелонированную защиту для предотвращения и сдерживания вторжений путем предоставления защитных мер, адаптированных к каждому типу активов.
Учитывая, что приложения являются одним из внутренних уровней, имеет смысл отдавать приоритет безопасности приложений. Это также имеет смысл, если учесть, что приложения являются внешним компонентом и, следовательно, предоставляют потенциальным хакерам очевидный путь в систему.
Вы не можете защитить интерфейс
Веб-приложения имеют высокую степень уязвимости и риска, поскольку браузеры по своей сути небезопасны. Это не обвинение браузеров; это констатация факта, основанная на архитектуре, навязанной средой выполнения. Для новых веб-разработчиков это почти обряд посвящения - попытки и безуспешные попытки защитить данные в браузере.
Одна из особенно чувствительных областей - это ключи и секреты, необходимые для аутентификации с помощью облачных сервисов. Например, приложения, использующие GitHub API, должны предоставить токен, чтобы идентифицировать себя как часть процесса аутентификации. Однако крайне важно хранить секреты в секрете, поскольку в случае их взлома злоумышленник может использовать их для кражи исходного кода или вандализма репо.
Соблазн фронтенд-безопасности
Ловушка, в которую часто попадают разработчики внешнего интерфейса, - это уверенность в том, что они в безопасности, храня секреты, такие как закрытые ключи и токены, где-то еще, а не в исходном коде. Каким бы важным ни было сохранение секретов приложения не в исходном коде, они небезопасны, если клиент работает в браузере.
Давайте рассмотрим это дальше, рассмотрев один метод, используемый для отделения данных от исходного кода, и то, как легко попасть в ловушку, полагая, что он обеспечивает определенную степень безопасности.
Переменные среды используются для экстернализации данных путем их перемещения из исходного кода в файл, например файл .env. Дополнительный шаг по добавлению этого имени файла в .gitignore не позволяет командам git push загружать его в репозиторий GitHub, где в случае общедоступных репозиториев он будет доступен любому.
Это не только скрывает значение переменной среды в коде, но и ссылка на нее по четко определенному имени также добавляет ясности исходной программе.
Маленький грязный секрет
Хорошо, это не секрет, но часто забывают, что .env файл не зашифрован. В случае Create React App это можно проверить с помощью параметра Developer Tools вашего браузера, чтобы проверить пакет, расположенный в каталоге build/static/js. Здесь вы обнаружите, что 0.chunk.js содержит переменные среды и их значения в виде открытого текста.
Так чем же использование переменных среды лучше, чем определение секретов в исходном коде? Разве это не означает, что приложение все еще находится в опасности?
Ответ заключается в том, что размещение секретов в переменных среды не обеспечивает значительного повышения безопасности и не снижает риск. Простой факт заключается в том, что данные на стороне клиента в браузере не могут быть должным образом защищены, и в лучшем случае этот метод только скрывает конфиденциальные данные от глаз.
Заманчиво рассмотреть сценарий, в котором разделение кода будет использоваться для отсрочки загрузки сценариев, содержащих переменные среды, до тех пор, пока приложение не аутентифицирует пользователя. Но это нарушает концепцию глубокой защиты, если клиентский компьютер скомпрометирован, поскольку файловая система будет доступна злоумышленникам.
Решение
В отличие от внешнего интерфейса, серверные приложения могут быть надлежащим образом защищены для защиты конфиденциальных данных. Эти меры защиты включают использование сервисов OAuth для обеспечения дополнительного уровня аутентификации и контроля доступа, шифрование для защиты данных в состоянии покоя и такие протоколы, как HTTPS и TLS для защиты данных в движении.
Дилемма о том, как защитить секреты приложения, может быть решена путем реализации API серверного приложения, который действует как прокси-сервер, чтобы изолировать интерфейсное приложение от поставщиков услуг, которые оно использует. Вместо того, чтобы использовать секреты во внешнем интерфейсе для аутентификации службы, API аутентифицируется от внутреннего приложения к внешней службе, выполняет запросы и затем возвращает только результаты во внешний интерфейс. Ни в коем случае личные ключи или секреты не открываются для внешнего интерфейса.
Завершение
Чтобы пользователи были уверены в том, что вы предприняли шаги, необходимые для защиты их информации, требуется тщательное планирование, хорошо продуманная стратегия безопасности, основанная на глубокоэшелонированной защите и внимании к деталям.
Недостаточно полагаться на «островки технологий». Надежное решение проблем безопасности требует понимания того, как информация передается между компонентами, чтобы выявить пробелы, слабые места и способы их устранения.
Обнадеживает, если проблема безопасности внешнего приложения беспокоит вас, и вы столкнулись с этой проблемой. Признание и согласие веб-разработчика с тем, что безопасность начинается с вас, показывает, что вы - ответственный человек и серьезно относитесь к своему делу.
Так держать и быть в безопасности!
Обновление 19.12.2018
Дополнительные сведения об использовании переменных среды в ваших приложениях см. В следующей статье.
Что такое Чингу?
Присоединяйтесь к нам на Chingu.io, чтобы выйти из Учебного чистилища, присоединившись к одной из наших удаленных проектных групп Voyage, чтобы создавать приложения, совершенствовать жесткие навыки и изучать новые мягкие навыки. Мы помогаем разработчикам преодолеть разрыв между тем, чему они научились, и навыками, которые ищут работодатели.
