Почему и как защитить конечную точку API👨⚕️

Это эпоха взрыва цифровой экономики, а массивные нагрузки данных передаются через API.

Бизнес, игры, образование, наука, искусство. , , вы называете все то, что работает на API.

Для мира, столь основанного на API, на удивление мало внимания уделяется безопасности.

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

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

Не очень красивое зрелище, если вы спросите меня.

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

Но давайте сначала. ?

Зачем защищать конечные точки API?

Нам нужно защищать конечные точки, потому что от того зависит бизнес.

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

Потеря бизнеса

Это очевидно.

Если кому-то удастся возиться с вашими конечными точками API, это приведет к остановке.

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

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

Вопросы соблюдения требований

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

Например, если вы обслуживаете банковскую отрасль (особенно в ЕС), стоимость обнаружения с использованием небезопасных API приведет к серьезным нарушениям законодательства.

Настолько, что это может даже означать конец вашего бизнеса.

Репутационные риски

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

Например, Sony была взломана очень серьезно несколько раз к , и в кругах безопасности компания является насмешищем.

Даже если не будет понесена никакая фактическая потеря данных или денег удачи, в попытках убедить своих клиентов в безопасности. ?

Счета за инфраструктуру

Когда ваш API работает в инфраструктуре, он потребляет ресурсы (пропускная способность, процессор и память, в основном).

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

На платформах, где включено автоматическое масштабирование ресурсов (например, AWS), результаты могут быть шокирующими.

Командный дух

Итак, вы можете подумать, команда, которая позволила бы этим компромиссам произойти, потеряет моральный дух?

Ну, не совсем.

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

Прибыль конкурентов

Итак, допустим, произошел сборй, но фактической потери денег не было.

Тем не менее, ваши конкуренты будут использовать этот инцидент, чтобы объединить свой собственный API и утверждать, насколько они более безопасны (даже если это не так!).

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

HTTPS всегда

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

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

Поэтому всегда делайте https единственным доступным вариантом.

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

Сертификат TLS не стоит дорого, вы можете купить за 20 долларов США в магазине SSL.

Одностороннее хеширование паролей

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

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

Единственным предлагаемым вариантом является асимметричный алгоритм шифрования (или «односторонний») для хранения паролей.

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

Сильная аутентификация

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

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

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

Применить ограничение скорости

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

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

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

Обеспечьте фильтрацию IP-адресов, если это применимо

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

Для каждого нового местоположения и новых клиентов IP-адрес должен быть проверен на входящий запрос.

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