Безопасность является ключевым аспектом разработки программного обеспечения. Почти каждое мобильное приложение имеет дело с пользовательской информацией или связывается с удаленным сервером. Несмотря на то, что безопасность значительно улучшилась за последние десятилетия, она продолжает оставаться предметом горячих дискуссий.
В этой статье я хотел бы выделить ряд тем, связанных с безопасностью и развитием мобильных устройств. Попутно я коснусь нескольких рекомендаций и предложений, которые могут оказаться полезными для защиты приложений, которые вы пишете.
Безопасность и конфиденциальность
Безопасность относительна. Эксплойты безопасности обнаруживаются и исправляются на регулярной основе. Ничто не идеально. Тем не менее, есть несколько вещей, которые вы можете сделать, чтобы улучшить безопасность ваших мобильных приложений. Грабитель менее искушен ворваться в здание, окруженное электрическим забором, чем тот, который не делает.
Некоторые разработчики упускают из виду тот факт, что пользователи их приложений доверяют им свою информацию. Как разработчик, вы несете ответственность за безопасность этой информации. Неважно, что это за информация. Хотя информация может показаться неважной для вас, она важна для пользователя.
Apple очень серьезно относится к безопасности и конфиденциальности. HealthKit является прекрасным примером приверженности Apple защите конфиденциальности пользователей. Пользователь решает, к каким данным о состоянии доступа приложение имеет доступ. Хотя приложение может запрашивать доступ к данным о здоровье пользователя, HealthKit не сообщает ему, к каким данным оно имеет доступ. Другими словами, Apple считает статус авторизации приложения конфиденциальной информацией, о которой он не должен знать.
1. Хранение данных
Если ваше приложение хранит данные
Прежде чем вы решите, как и где хранить конкретный фрагмент данных, вам нужно спросить себя, следует ли вам хранить эти данные в первую очередь. Можно ли, например, хранить данные в памяти, а не записывать их на диск или отправлять на удаленный сервер? Это может значительно упростить архитектуру вашего приложения и повысить его безопасность.
Где вы должны хранить данные
Если вы решите, что хранение данных локально — ваш единственный вариант, вам нужно решить, где вы планируете хранить эти данные. Для конфиденциальной информации, такой как учетные данные, брелок является вашим лучшим вариантом. Это возможно только для небольших объемов данных, к которым ваше приложение не нуждается в частом доступе.
Нужно ли создавать резервные копии данных в iCloud или iTunes? Если это не так, то вы можете рассмотреть возможность сохранения данных в каталоге Caches в изолированной программной среде приложения. Этот каталог не резервируется в iCloud и iTunes. Почему это важно? Данные, которые не существуют, не могут быть скомпрометированы.
Брелок
Система по умолчанию, доступная через класс NSUserDefaults , является быстрым и удобным способом хранения фрагментов данных. К сожалению, система по умолчанию часто используется разработчиками. Слишком часто случается, что конфиденциальная информация, такая как учетные данные и токены доступа, хранится в системе значений по умолчанию.
Намного лучшим местом для хранения небольших фрагментов конфиденциальной информации является системная цепочка для ключей. Как следует из названия, он был разработан с учетом безопасности и существует уже много-много лет. Несмотря на то, что цепочка для ключей управляется операционной системой, по умолчанию другие приложения не имеют доступа к элементам, которые ваши приложения хранят в цепочке для ключей.
Это правда, что интерфейс для доступа к сервисам цепочки для ключей является архаичным. К счастью, есть несколько отличных библиотек, которые преодолевают это препятствие. Например, Lockbox — это легковесная библиотека для взаимодействия со службами цепочки для ключей системы. Интерфейс Lockbox прост в использовании и понимании.
Ключи, токены, учетные данные
Соблазнительно хранить ключи, токены и даже учетные данные в легко доступных местах, таких как Info.plist цели или файл JSON в комплекте вашего приложения. Правда в том, что извлекать эту информацию из приложения, загруженного из App Store, — детская игра. Сохраняя токен API для веб-службы в Info.plist вашего приложения, другие разработчики могут найти его и использовать.
2. Сеть
App Transport Security
Безопасность и конфиденциальность были в повестке дня Apple на протяжении многих лет, и вместе с другими крупными игроками Apple решила подавать пример. Во время прошлогодней WWDC компания представила App Transport Security .
С помощью App Transport Security Apple стремится повысить безопасность своих платформ и приложений, работающих на них. Независимо от того, сколько Apple инвестирует в обеспечение безопасности своих операционных систем, система является настолько же безопасной, насколько ее самый слабый компонент, и включает в себя сторонние приложения.
App Transport Security принудительно заставляет приложения отправлять сетевые запросы через безопасное соединение. Если App Transport Security включена для приложения, сетевые запросы отправляются по HTTPS по умолчанию. Apple подчеркивает свою приверженность безопасности и конфиденциальности, автоматически включая App Transport Security для приложений, созданных с Xcode 7.
Вы можете узнать больше о App Transport Security на Envato Tuts + . Хотя App Transport Security легко отключить, имейте в виду, что одна из целей App Transport Security — заставить разработчиков учитывать поведение своих приложений в сети.
С кем я разговариваю
Практически каждое мобильное приложение использует сеть. Это означает, что люди с плохими намерениями сосредоточены на этом аспекте безопасности приложений. Работа в сети — сложный вопрос, и приложения основываются на множестве технологий для извлечения интересующих их данных.
Как разработчик, важно придерживаться ряда лучших практик. Мы уже обсуждали App Transport Security и правила, которые применяет эта новая технология. Это не останавливается там, все же. Вы также можете изучить более сложные темы, такие как закрепление сертификатов, чтобы убедиться, что сервер, с которым взаимодействует ваше приложение, не является мошенническим. Современные библиотеки, такие как Alamofire , делают это намного проще.
3. Чувствительная информация
Данные пользователя
Большинство приложений используют или хранят конфиденциальную информацию пользователя. Мобильные устройства имеют доступ к широкому спектру пользовательской информации, которая часто носит личный и конфиденциальный характер, например, местоположение, адресная книга и информация о состоянии здоровья.
Как я уже упоминал ранее в этой статье, первый вопрос, который вам нужно задать себе, — нужен ли вам доступ к этой информации и, что более важно, нужно ли вам хранить эту информацию.
Если вы можете получить доступ к необходимой вам информации через встроенную среду, например HealthKit, вам не нужно дублировать и хранить эту информацию. Например, Apple будет отклонять приложения, которые хранят информацию о здоровье пользователя в iCloud .
Держите это Местным
Предполагая, что вам нужно хранить некоторую конфиденциальную информацию, подумайте, должна ли эта информация храниться локально. Нужно ли отправлять конфиденциальную информацию на удаленный сервер?
Хранение конфиденциальной информации сопровождается предупреждением. Если сервер, на котором вы храните конфиденциальную информацию, скомпрометирован, вы можете нести ответственность за раскрытие этой информации другим сторонам.
полномочия
За последние десятилетия безопасность в сети значительно изменилась. Протоколы аутентификации, такие как OAuth , сделали связь с веб-сервисами более безопасной и прозрачной.
Если ваше приложение должно общаться с защищенным сервером, подумайте, как ваше приложение управляет учетными данными. Хранит ли он их в памяти или сохраняет на диске? Если вы попросите имя пользователя и пароль пользователя получить токен доступа, то этот токен можно сохранить. Но вы должны также хранить имя пользователя и пароль? Ответ — нет в большинстве ситуаций.
Для приложений, работающих с очень конфиденциальными данными, такими как медицинская или финансовая информация, может быть даже лучше хранить токен доступа в памяти, а не хранить его на диске. Хранение его в памяти делает его намного безопаснее, делая ваше приложение намного менее ответственным. Скорее всего, токен доступа имеет короткий срок службы в любом случае.
Вывод
Безопасность приложения является фундаментальным аспектом разработки программного обеспечения. Подумайте, к каким данным ваше приложение имеет доступ и должно ли оно хранить эту информацию. Если вы решили хранить конфиденциальную информацию, помните о приведенных выше советах и рекомендациях. Убедитесь, что вы относитесь к информации пользователя с уважением. Даже если информация может показаться неважной для вас, она важна для пользователя.