Через серые зоны — к 4,7 звезды. Как мы сделали топовое security-приложение для iOS

Скажу сразу: у нас нет и не было задачи состязаться с Apple или что-то им доказать. Просто когда мы делали мультиплатформенное решение Kaspersky Security Cloud, то увидели в iOS области, где мы можем дополнительно защитить данные пользователей. Конкретно в случае с антифишингом речь идёт о защите от перехода по ссылкам из браузера и других приложений, которые могут вести на вредоносные ресурсы.

iOS является крайне сложной для взлома, но этого не всегда достаточно. К примеру, самая распространенная атака на iOS сегодня — это кража Apple ID. Получив доступ к такому аккаунту, злоумышленники могут заблокировать устройство и потребовать выкуп за разблокировку, получить доступ к личным данным (фото, заметкам и т. д.), а также к другим устройствам, к которым привязан Apple ID.

При этом антифишинговые технологии дают нашему iOS-продукту определённые свойства антивируса, но не делают его таковым в классическом смысле. Под антивирусом же обычно понимается что-то, что может проверить содержимое всех носителей и выдать вердикт по каждому файлу, а в случае с iOS такой механизм просто нереализуем в силу технических особенностей ОС. В этом и основное отличие от Android — там, если есть опасность получить malware именно в формате APK, нужен как раз именно файловый антивирус. У iOS cвои особенности в векторах атак, соответственно, свои способы защиты, а значит, всё должно быть построено совсем по-другому.

И ещё: поскольку iOS достаточно закрыта, то в ней есть серые зоны, и мы столкнулись с ними в рамках разработки антифишинга: на что-то потратили слишком много ресурсов, а какие-то технические решения делали экспериментальным путём на основе нашего опыта. Итак…

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

Мы с самого начала понимали, что делаем продукт с множеством компонентов, зависимостей, бэкенда и всего прочего. И надо учесть, что это защитное приложение, которое по определению должно разрабатываться по концепции SDL (Security Development Lifecycle). Плюс бо́льшая часть фич была нацелена на мониторинг безопасности настроек (jailbreak detection), мониторинг утечек данных (compromised accounts), а также обнаружение и трекинг новых устройств в домашней Wi-Fi-сети (New home device protection). Вы ещё не сбились со счёта? Ага, и всё это должно работать быстро, не сжирать почём зря батарейку и иметь современный UI/UX. Значит, дополнительно нужны тестировщики, аналитики, технические писатели, локализаторы, проектировщики интерфейсов, графические дизайнеры. В какие-то моменты на стендапе собиралось до 20 человек.

Тут всё по классике. Kaspersky Security Cloud существует не первый год, core-функционал мы пилили в самом начале: работали на результат, стабилизировали и выпустили в прод. Безусловно, всегда идёт работа по рефакторингу каких-то частей, но остаются и серые зоны. И разобраться, почему и для чего были приняты те или иные решения, получается не сразу. В нашем случае мы по определению не могли пройти мимо рефакторинга. И, конечно, нашли много чего интересного. В том числе «костылей», от которых было решено отказаться.

• В предыдущих версиях была достаточно высокая связность кода. Соответственно, в рамках рефакторинга нам потребовалось перегруппировать объекты и делать их более самостоятельными.
• За время жизни продукта накопились разные нюансы. Например, были вызовы частей кода, закрытых флагами компиляции. При этом, как позже выяснилось, фактически эти части не должны были вызываться. Поэтому в рамках рефакторинга также «причёсывали» код, чтобы избежать лишнего мусора.
• Было дублирование кода в разных местах. Например, это касалось логики показа нотификации при включении безопасного соединения. В рамках рефакторинга также делали более универсальную логику и исключали дублирование.
• Был файл, в котором было около 50 % кода (а это несколько тысяч строк!), god object. По итогам рефакторинга его распилили примерно на 200 файлов и привели в соответствие с SOLID.
• Было небольшое покрытие автотестами core-части безопасного соединения. Изначально это затрудняло процесс рефакторинга и отладки. Вместе с рефакторингом мы решили и эту задачу, что позволило в дальнейшем упростить развитие и поддержку этой части продукта.
• Возвращаясь к антифишингу: поскольку его реализация связана с работой локального безопасного соединения, перед нами встала задача, связанная с масштабированием работы extension, так как раньше он был полностью завязан на состояние безопасности туннеля. В случае с антифишингом мы решали задачу, как сохранить extension в живых при выключенном безопасном соединении.

Но, как я уже говорил, iOS достаточно закрыта как для разработчиков ПО, так и для производителей защитных приложений, и ряд ограничений и технических особенностей толком не задокументированы. Это затрудняло как разработку, так и тестирование — не видя весь объём ограничений системы и окружения, достаточно сложно управлять продуктом. Так что очень многое приходилось встречать «лбом о стену». Но в конечном итоге нам помог весь накопленный компанией опыт работы с мобильными платформами.

Принято считать, что, если ты делаешь сложную технологическую фичу, надо сначала сделать прототип и только после этого давать какие-то оценки и что-то планировать. Есть, например, уже упомянутая функция мониторинга новых устройств в сети (New home device protection, NHDP) — она показывает устройства, которые подключены к домашней сети Wi-Fi, и с её помощью можно предотвратить подключение к домашней сети неавторизованных устройств и проверить состояние защиты устройств, подключённых к сети. Она должна была работать на базе общего компонента для всех платформ. Однако на iOS на данный момент универсальное решение не работает так, как задумано. Причём это стало понятно уже после прототипа, когда появилась первая боевая версия. В результате у нас появилась особая реализация компонента конкретно под iOS: туда была добавлена логика по анализу дополнительных параметров / протоколов, которые важны и специфичны именно для работы на iOS-устройствах.

Вообще, история NHDP на iOS достаточно занимательна и в каком-то смысле знаковая для нас, поэтому остановлюсь на ней чуть подробнее.

Если не ошибаюсь, дело было в 2016 году. Было принято решение реализовать фичу NHDP на всех платформах, для которых существует наше решение, — Windows, macOS, Android, iOS. И логично, что движок, который будет отвечать за сканирование сетей и выявление новых устройств, должен быть кросс-платформенным. И за его разработку взялась команда поддержки и развития общих компонентов.

Первые версии разработанного движка безупречно определяли в сети только виндовые машины. В итоге пришлось существенно расширять функциональность движка и поддерживать дополнительно сканирование по различным broadcast-протоколам, таким как UPnP, mDNS, Bonjour и др., чего, насколько я помню, в первом релизе изначально и не планировалось. Так что мы со своей стороны организовали мощное тестирование. Кабинет руководителя мобильной разработки «Лаборатории Касперского» стал своеобразным стендом, где мы поставили Wi-Fi-точку и принесли туда всевозможные устройства: PlayStation, Smart TV, носимые устройства, разные смартфоны. И каждую новую «поставку» плотно тестировали на этом стенде и фиксили десятки багов.

Но тут с iOS кое-что произошло. В продолжающейся борьбе за приватность пользователей в iOS 10.2 Apple неожиданно запретила получение MAC-адресов устройств в сети через ARP-таблицы, просто по всем устройствам в сети стал значиться один и тот же MAC-адрес — 02:00:00:00:00:00. Причём сделано это было внезапно: никаких предупреждений на WWDC, никаких информирующих сообщений, никаких дисклеймеров в документации — просто запретила, и всё.

А для нашего движка MAC-адрес устройств был ключевой для его функционирования сущностью: по нему определялись тип и вендор устройства, на него была сильно завязана бизнес-логика по определению новых устройств в сети и т. д. В общем, наш движок стал нерабочим, но, к слову, с похожей проблемой столкнулись и другие разработчики приложения в App Store со схожей функциональностью — все они разом превратились в тыкву. И в этом плане нам ещё повезло, если можно так выразиться, потому что для некоторых таких приложений, к сожалению, это была основная, а порой и единственная фича.

Обидно — мы уже были на финишной прямой: разработка фичи завершена, шло функциональное тестирование, а тут… Тогда, подключив наше Anti-Malware Research подразделение, совместно мы смогли найти воркэраунд, обойти ограничения и реанимировать фичу. Но с выходом очередной версии iOS из соображений безопасности пользователей ОС доступ к MAC-адресам оказался ограничен, что существенно снизило полезность фичи. Мы временно скрыли её в продукте, так как не могли позволить себе выпускать её в подобном качестве в прод, и продолжили искать альтернативные решения (и, кстати, нашли!)

В общем, много усилий ушло на то, чтобы подпилить всё для работы в новых условиях. Дополнительно нам потребовалось достаточно серьёзно переработать core-компоненты продукта для того, чтобы поднять антифишинг, — в противном случае у нас бы получился слоёный пирог из старой архитектуры, legacy-кода и новой технологии, который нам бы просто не удалось стабилизировать.

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

Ещё для реализации antiphishing- / antimalware-фичи мы должны были научиться работать в условиях ограничений по ресурсам на уровне iOS. При этом сложность была не столько в самой технологии, сколько в том, что эти самые ограничения и лимиты опять же недостаточно подробно задокументированы.

Высокая оценка после релиза (4,7 звезды) в App Store, безусловно, не могла нас не порадовать. Но мы хотим развивать продукт дальше, и помимо благодарностей мы всегда с большим интересом вчитываемся в фидбэк, с которым к нам приходят пользователи.

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

Далее мы хотим ещё больше увеличить скорость работы и оптимизировать потребление памяти. Ещё одна большая задача — доработать технологию анализа трафика и повысить качество детекта. Также в планах много работы по кастомизации продукта для наших партнёров. Ну и конечно же, в бэклоге есть достаточно большое количество крутых новых фич, которые нам ещё только предстоит реализовать. В частности, это касается ранее упомянутого NHDP, для которого на данный момент у нас уже есть техническое решение и прототип для реализации на современных версиях iOS.

Вообще, то количество технических вызовов, с которыми сейчас сталкивается наша команда мобильной разработки, показывает, насколько сильно конкуренция среди приложений повысила планку ожиданий у рядовых пользователей. Мало хорошей идеи и неистребимого энтузиазма, и даже продуманный UX и красивая графика не спасут, если приложение будет нестабильно, — пользователи незамедлительно его снесут. А если продуктовая ниша новая, то мгновенно научившиеся на твоих ошибках конкуренты просто выдавят тебя с рынка. Это только в теории можно однозначно «выстрелить» с любых стартовых условий, но состоявшимся компаниям, обладающим бо́льшими ресурсами, опытом разработки и запуска приложений, может быть объективно легче. Соответственно, и у разработчиков из компаний-гигантов больше шансов поучаствовать в создании такого продукта и внести в его успех свой персональный вклад.

Мне есть с чем сравнить — я пришёл в «Лабораторию Касперского» в 2012 году в роли системного аналитика на проектах по разработке мобильных приложений. Для меня на фоне моего прежнего опыта это была какая-то параллельная вселенная, если говорить об уровне экспертизы коллег, качестве процессов и уровне понимания разработки в принципе. Тогда я даже не надеялся, что моя скромная кандидатура может заинтересовать компанию. Плюс у меня не было соответствующего бэкграунда в сфере продуктовой разработки; вообще, если бы я знал, насколько сильно я недооценил уровень своего незнания, то и вовсе бы не решился пойти на собеседование. Но, видимо, мне на руку сыграло то, с каким напором и энтузиазмом задавал вопросы по проекту и что я довольно нагло заявлял, что «так жить нельзя», и сходу предлагал, как всё надо перестроить.

Примерно через год после того, как я пришёл в «Лабораторию Касперского», начался бурный рост мобильной экосистемы и отдел из 10 разработчиков за короткое время вырос в управление со 100+ сотрудников. Количество аналитиков также в разы увеличилось, и в итоге спустя несколько лет я возглавил группу аналитиков на мобильных проектах, а затем вырос до Head of Mobile Cloud Services Development. Сейчас наш Kaspersky Security Cloud для iOS ждёт новая итерация роста. На это приложение мы в компании делаем ставку с точки зрения продвижения, и уже сейчас видим, что к нему проявляют интерес в Германии, США, Великобритании, а также в других европейских странах. И конечно, в России. Поэтому для меня и моей обновленной команды (сейчас мы ищем iOS-разработчиков уровня от крепкого middle и выше), это будет крутой профессиональный вызов.