Большинство предприятий используют мобильные приложения, чтобы дополнить свои деловые усилия, будь то коммуникация или инструмент для связи персонала с ресурсами. Хотя некоторые готовые приложения идеально подходят для организаций, разработка пользовательских корпоративных мобильных приложений может быть невероятно полезна для выполнения задач, которые невозможны при наличии стандартных приложений, доступных на проверенных торговых площадках, таких как Google Play или iOS App Store.
Проблема в том, что когда разработка пользовательских приложений становится новым понятием для вашего бизнеса, это будет ошеломляющим. Помимо получения желаемой функциональности и UX, в вашем ИТ-отделе неизбежно будут большие оговорки в отношении безопасности.
Опасения реальны, что заставило некоторые компании либо затормозить, либо вообще отказаться от этой идеи. Тем не менее, при хорошем планировании мобильное приложение может повысить производительность пользователей или увеличить внешнее взаимодействие, при условии что разработка основывается на разумных методах обеспечения безопасности ИТ.
Бизнес-приложение устрашает многие организации, потому что там так много «неизвестных, неизвестных». Именно этот страх перед чужой концепцией часто вызывает своего рода предвзятость, когда лица, принимающие решения, исследуют проблемы с разработкой корпоративных мобильных приложений, читают страшные истории, а затем думают: «Это не для нас».
Хотя это может показаться ошеломляющим или невозможным, есть несколько вопросов, которые лица, принимающие решения в области ИТ, на предприятии - или на самом деле, любая компания с несколькими движущимися частями - могут задать в процессе принятия решения о разработке проекта приложения.
Насколько конфиденциальны ваши данные? Даже если вы не связаны правилами соответствия данных, такими как HIPAA или GDRP (среди многих других), понимание того, какие правила предписывают хранение и использование данных, возможно, является самым большим компонентом безопасности.
Какова цель вашего приложения? Есть приложения, которые действуют как простые клиенты для веб-контента. Другие могут использоваться для доступа к аналитике, чтобы помочь отделам продаж или производства получать информацию в режиме реального времени. Поистине, существует множество способов использования приложения - основным элементом в начале работы является определение того, что вы хотите, чтобы ваше приложение делало.
Кто будет использовать приложение? Внутренние и внешние пользователи будут предъявлять различные требования в зависимости от функциональности приложения. В любом случае необходимо понимать, как приложение будет использоваться любой группой, поскольку будут разные требования как с точки зрения функциональности, так и безопасности для каждого сценария.
Как вы будете защищать другие бизнес-системы? Важно учитывать системы и базы данных, к которым будет обращаться приложение, особенно когда они находятся за пределами брандмауэра и если широкая публика сможет подключиться. Вам нужно будет выделить ресурсы и время для команд на исправление и блокировку этих систем, чтобы предотвратить причинение вреда злоумышленникам.
Планируете ли вы нанять или нанять разработчика приложения для создания приложения, перечисленные ниже основные факторы, которые следует учитывать в отношении безопасности приложений и разработки мобильных приложений для предприятий. Здесь мы собираемся обратиться к лидерам мобильной безопасности OWASP за рекомендациями по мобильным приложениям, объяснив основные угрозы для безопасности мобильных устройств и базовые методы снижения рисков.
Избегайте небезопасного использования платформы для внутренних пользователей. Многое из этого зависит от серверной CMS или сервера, на котором хранится контент, в дополнение к API, который извлекает данные из любой системы. Все, что имеет разрешения высокого уровня, должно использовать TouchID или Keychain для хранения учетных данных и токенов доступа - никогда не храните незашифрованную информацию пользователя в локальном хранилище. В противном случае пользователи или системы должны проходить проверку подлинности через другую службу, например AD, 2FA, решение MDM и т. Д.
Защита данных. Не рискуйте подвергать данные чему-либо, что не требует использования. На самом деле, вам лучше всего исключить доступ к конфиденциальной информации через приложения, поскольку фишинговые схемы и другие эксплойты могут предоставлять данные непривилегированным пользователям, например вызывать нарушения, которые нарушают соответствие нормативным данным, прямые финансовые потери или возникновение любого другого числа проблемы. В идеале данные, хранящиеся в облачном хранилище или на локальных устройствах, также должны быть защищены, когда они не находятся в пути.
Правильное общение. Без соответствующих рукопожатий, подтверждения SSL-сертификатов или других методов зашифрованной доставки злоумышленникам может быть предоставлен широкий спектр данных. Транспортный уровень при обмене данными должен быть безопасным, даже если вы просто доставляете веб-контент через приложение.
Используйте хорошую аутентификацию и авторизацию для систем, ориентированных на потребителя. Для внешних пользователей, которые будут подключаться к бэкэнд-системам, лучше всего использовать технологии специально для доступа к B2C. Например, мобильные приложения Azure для этой цели работают с Azure Active Directory B2C. Аутентификация может быть привязана к другим учетным записям (например, Facebook, Google, LinkedIn и т. Д.) Для управления идентификацией, что также предоставляет потребителю дополнительный уровень защиты.
Применять методы безопасной разработки. Перед развертыванием приложения необходимо проверить клиентский код, а также бэкэнд-системы - но на этом все не заканчивается! Постоянный анализ кода должен быть обычной практикой, чтобы гарантировать, что мобильные клиенты и серверы используют самые последние исправления платформы. ИТ-персонал, который управляет этими системами, должен также позаботиться о том, чтобы они также следовали передовым методам, таким как использование 2FA и внесение в белый список IP-адресов через VPN для предотвращения атак «человек посередине» (среди прочих). ваши проекты с открытым исходным кодом, не храните конфиденциальный исходный код, который можно использовать для обратного инжиниринга вашего приложения в общедоступном git-репозитории.
Фальсификация и реверс-инжиниринг. Каждое приложение может быть подвергнуто обратному проектированию, поэтому разработчики должны уменьшить или устранить улики, которые могут разблокировать доступ к защищенным данным. В то время как комментирование полезно для кодовых наборов, чрезмерное комментирование может иногда показывать слишком много. Помимо того, чтобы избегать использования публичных представителей git, функции, которые имеют отношение к доступу к защищенным частям бизнес-сети, должны быть исключены или, по крайней мере, скрыты. Например, исходный код не должен содержать никаких ключей API, учетных данных пользователя или конкретной информации о конфигурации, которые могут быть использованы для подделки вашего приложения или для повторного использования закрытого исходного кода.
Устранить черные ходы. Для удобства и тестирования разработчики могут оставлять бэкдоры в коде, который пропускается и впоследствии не закрывается до развертывания. Даже если некоторые кодеры могут сделать это для удобства, обязательно, чтобы эти лазейки были удалены до того, как приложение станет доступным для конечных пользователей.
Для многих предприятий это нервная ситуация, когда речь идет о разработке, развертывании и использовании мобильного приложения. Хорошая стратегия необходима для безопасного приложения, которое может повысить производительность или расширить взаимодействие с внешними пользователями. Обсуждая и анализируя ключевые подводные камни безопасности, организации будут хорошо оснащены, чтобы их приложение обеспечивало безопасную работу.