راهنمای توسعه‌دهندگان موبایل به سمت کهکشان: فصل هشتم

فصل هفتم را از این جا بخوانید.

فصل هشتم: امنیت و حریم خصوصی (Security & Privacy)

نویسنده: دین چرچیل (Dean Churchill)

کهکشان اپلیکیشن‌های موبایل، فراتر از مجموعه‌های (constellations) iOS، اندروید و چند پلتفرم گوشی هوشمند دیگر گسترش یافته است. اپلیکیشن‌ها بر روی مجموعه‌ای از دستگاه‌ها، که پیوسته در حال افزایش هستند، در حال توسعه و استقرار می‌باشند: کنسول‌های بازی، پلتفرم‌های تلویزیون، واقعیت مجازی/افزوده (virtual/augmented reality)، پهپادها (drones)، دستگاه‌های پوشیدنی (wearables)، دستگاه‌های آینه‌سازی صفحه نمایش (screen mirroring devices)، و صفحه‌های نمایش سرگرمی در خودرو (in-car infotainment screens). این اپلیکیشن‌ها به سرویس‌های ابری (cloud services) متصل شده و دستگاه‌های اینترنت اشیا (IoT devices) را مدیریت کرده و با آن‌ها تعامل دارند. فضای اپلیکیشن‌ها از بی‌ضررترین اپلیکیشن‌های چراغ قوه تا اپلیکیشن‌های حیاتی برای نظارت بر مکان، ایمنی و سلامت افراد مبتلا به بیماری‌های مزمن را شامل می‌شود. فراتر از کسب‌وکار، امور مالی و شبکه‌های اجتماعی، اپلیکیشن‌های موبایل سیستم‌های امنیتی و نظارتی خانه را کنترل می‌کنند، پهپادها را به پرواز درمی‌آورند و ابزارهای صنعتی را اجرا می‌کنند. با افزایش زنجیره ارزش اپلیکیشن‌های موبایل، تلاش‌های بی‌وقفه هکرها برای به خطر انداختن این سیستم‌های نرم‌افزاری به منظور سرقت پول، برهم زدن انتخابات، جاسوسی از رقبا، تعقیب، ارتکاب کلاهبرداری، و از کار انداختن یا به دست گرفتن شبکه‌ها نیز افزایش می‌یابد. همزمان، تنظیم‌کنندگان در سراسر جهان در حال تدوین قوانین جدیدی در مورد حفظ حریم خصوصی داده‌ها هستند که برد وسیعی دارند. این یک درام تعقیب دوگانه است: شما در خطر تعقیب هم توسط افراد بد و هم افراد خوب قرار دارید. مجرمان می‌خواهند داده‌های شما را بدزدند یا باج‌گیری کنند، در حالی که تنظیم‌کنندگان در صورت عدم امنیت و محافظت از داده‌های مشتریان، شما را جریمه خواهند کرد. بنابراین، اکنون بیش از هر زمان دیگری، باید بر طراحی راه‌حل‌های امن سرتاسری (end-to-end solutions) با استفاده از اپلیکیشن موبایل خود به عنوان یک نقطه پایانی (end point) و ارائه حفاظت از حریم خصوصی برای داده‌هایی که اپلیکیشن استفاده می‌کند، تمرکز کنید. این امر مستلزم در نظر گرفتن اپلیکیشن موبایل در زمینه خدمات ابری و بک‌اند (backend services) و دانستن محل و نحوه ذخیره داده‌های شما است.

این راهنمای بسیار مختصر در مورد امنیت و حریم خصوصی به چند رویکرد برای مدل‌سازی تهدید (threat modeling)، مسائل کلیدی در مقررات حفظ حریم خصوصی (privacy regulations) و یک رویکرد برای آزمایش امنیت (security testing) می‌پردازد. در حالی که وظیفه ایمن‌سازی یک اپلیکیشن ممکن است دلهره‌آور به نظر برسد، اکثر حملات به اپلیکیشن‌ها، چه اپلیکیشن‌های وب، دسکتاپ یا موبایل، می‌توانند با تکنیک‌های ساده کدنویسی امن (secure-coding techniques) و آزمایش امنیتی اولیه (basic security testing) دفع شوند.

مدل‌سازی تهدید (Threat Modeling)

نقطه شروع برای طراحی‌های امن فناوری اطلاعات (IT designs) ایجاد یک مدل تهدید است. یک مدل تهدید با فهرست کردن تمام دارایی‌های (assets) مورد نگرانی محصول شما آغاز می‌شود. دارایی‌ها شامل تمام اجزای نرم‌افزاری (software components)، سخت‌افزار (hardware)، شمای داده (data schemas) و انباره‌های داده (data stores)، رابط‌های برنامه‌نویسی کاربردی (APIs)، میکروسرویس‌ها (microservices)، رابط‌ها (interfaces) و کانال‌های ارتباطی (communication channels) مورد نیاز برای عملکرد محصول شما هستند. سپس برای هر یک از این دارایی‌ها یک مدل تهدید ایجاد کنید. مدل‌های تهدید متعددی برای کمک به تحلیل وجود دارد.

لیست «۱۰ مورد برتر موبایل OWASP» (OWASP Mobile Top 10)» تهدیدات غالب را برای پلتفرم‌های موبایل شناسایی کرده است: استفاده نادرست از پلتفرم (improper platform usage)، ذخیره‌سازی ناامن داده‌ها (insecure data storage)، ارتباطات ناامن (insecure communications)، احراز هویت ناامن (insecure authentication)، رمزنگاری ناکافی (insufficient cryptography)، مجوزدهی ناامن (insecure authorization)، کیفیت کد مشتری (client code quality)، دستکاری کد (code tampering)، مهندسی معکوس (reverse engineering) و عملکرد اضافی (extraneous functionality). OWASP مواد تکمیلی گسترده‌ای در مورد ماهیت تهدیدات، نحوه کدنویسی امن در برابر آن‌ها و آزمایش اپلیکیشن‌ها ارائه می‌دهد.

«اتحادیه امنیت ابری» (Cloud Security Alliance (CSA)) بر تهدیدات مربوط به سرویس‌های ابری متمرکز است و آموزش و ابزارهایی را برای ارزیابی تهدیدات مربوط به رایانش ابری (cloud computing) ارائه می‌دهد. CSA یک «ماتریس کنترل‌های ابری» (Cloud Controls Matrix) رایگان ارائه می‌دهد که به ارزیابی خطرات یک ارائه‌دهنده ابری کمک می‌کند.

مدل امنیتی «استراید» (STRIDE security model) توجه را بر طراحی نرم‌افزار متمرکز می‌کند تا در برابر تهدیدات خاص «جعل هویت» (Spoofing)، «دستکاری» (Tampering)، «انکار» (Repudiation)، «افشای اطلاعات» (Information disclosure)، «محرومیت از سرویس» (Denial of service) و «افزایش سطح دسترسی» (Escalation of privilege) محافظت کند. این مدل به همان اندازه برای نرم‌افزارهای سمت سرور (server-side software) و همچنین کلاینت‌های موبایل (mobile clients) کاربرد دارد.

کنترل‌های امنیتی (Security controls) آن دسته از نرم‌افزارهایی هستند که نوشته شده‌اند و رویه‌هایی هستند که برای کاهش خطرات برای همه دارایی‌ها رعایت می‌شوند. به عنوان مثال، هر یک از تهدیدات برشمرده شده در مدل STRIDE می‌تواند با یک یا چند عنصر طراحی اپلیکیشن شما مقابله شود.

جعل هویت (Spoofing)

حملات جعل هویت دو نوع اساسی دارند. هویت یک کاربر ممکن است توسط یک هکر جعل شود، با وانمود کردن به اینکه او کسی است که نیست. اینجاست که احراز هویت قوی (strong authentication) برای اطمینان از اینکه کاربران اپلیکیشن شما همان کسی هستند که ادعا می‌کنند، وارد عمل می‌شود. کاربران ممکن است قربانی سرویس‌های جعلی نیز شوند. حمله کلاسیک فیشینگ (phishing attack) زمانی است که شما یک پیام جعلی (SMS، ایمیل، تماس صوتی) دریافت می‌کنید که از شما می‌خواهد وارد حساب بانکی خود در URL داده شده شوید. اغلب پیام حس فوریت را القا می‌کند. اما URL برای بانک مورد انتظار شما نیست، بلکه یک لینک به وب‌سایتی است که دقیقاً شبیه بانک به نظر می‌رسد. هکرها امیدوارند کسی نام کاربری و رمز عبور خود را در آنجا وارد کند، سپس آنها می‌توانند از آن اعتبارها (credentials) برای ورود به بانک واقعی و انتقال پول استفاده کنند.

در حالی که نمی‌توانید هکرها را از ارسال پیام‌های جعلی به مشتریان خود بازدارید، می‌توانید سیاستی مبنی بر عدم تماس با مشتریان برای درخواست ورود به سیستم داشته باشید. به مشتریان خود بگویید که هرگز برای درخواست رمز عبور آنها با آنها تماس نخواهید گرفت یا ایمیل‌های ناخواسته حاوی URL به دامنه وب شما ارسال نخواهید کرد. در عوض، می‌توانید از آنها بخواهید اپلیکیشن موبایل شما را از یک فروشگاه اپلیکیشن عمومی (public app store) دانلود کنند و از طریق اپلیکیشن وارد سرویس شما شوند. این فرآیند جعل کردن را دشوارتر می‌کند، تا زمانی که هیچ اپلیکیشن مخربی در فروشگاه اپلیکیشن وجود نداشته باشد که شبیه اپلیکیشن شما باشد. برای این منظور، باید مراقب فروشگاه‌های اپلیکیشن باشید و مطمئن شوید که نام شرکت و مالکیت معنوی (intellectual property) شما توسط هیچ اپلیکیشنی که مجاز نکرده‌اید، استفاده نمی‌شود.

دستکاری (Tampering)

حملات دستکاری ممکن است علیه نرم‌افزار، داده‌ها، پایگاه‌های داده، فایل‌ها و شبکه‌های ارتباطی (communications networks) هدایت شوند. دستکاری بسته‌های نرم‌افزاری (software packages) با امضای دیجیتالی بسته‌ها (مانند فایل‌های IPA iOS و APK اندروید) جلوگیری می‌شود. اما پس از نصب بر روی دستگاه‌های موبایل، هکرها با گوشی‌های روت‌شده/جیل‌بریک‌شده (rooted/jailbroken phones) می‌توانند نرم‌افزار و داده‌ها را به دلخواه دستکاری کنند. آنها می‌توانند کتابخانه‌ها (libraries) را با کتابخانه‌های هک‌شده جایگزین کنند، محتویات حافظه را در زمان اجرا (run time) تغییر دهند، باینری (binary) را پچ (patch) کنند و به طرق دیگر اپلیکیشن را به نفع خود منحرف کنند.

از این رو، طراحی شما نباید به دستگاه کاربر اعتماد کند. اقدامات متقابل شامل موارد زیر است: اسرار (رمز عبور، کلیدهای API، داده‌های حساس) را در فایل‌های IPA یا APK خود ذخیره نکنید، زیرا هکرها دسترسی کامل به تمام اطلاعات موجود در آن‌ها دارند. فایل Android Manifest در APKها و فایل Info.plist در فایل‌های IPA را بررسی کنید تا مطمئن شوید هیچ اسراری در آن‌ها وجود ندارد. به طور کلی، هر نوع محاسبات حساس، مانند شناسایی کاربر، احراز هویت و مجوزدهی، یا یک الگوریتم اختصاصی (proprietary algorithm)، باید در سمت سرور (server-side) انجام شود تا این توابع از دید هکرها دور بمانند. داده‌های حساس در صورت امکان نباید در دستگاه موبایل ذخیره شوند، در غیر این صورت از یک مکانیسم ذخیره‌سازی رمزگذاری‌شده (encrypted storage mechanism) مانند «کلیدشین» (keychain) موجود برای iOS و اندروید استفاده کنید. دستکاری داده‌ها در حافظه (storage) می‌تواند با استفاده از هش‌های رمزنگاری امن (secure cryptographic hashes) و امضاهای دیجیتالی (digital signatures) شناسایی شود.

بسیاری از اپلیکیشن‌های موبایل از پایگاه داده‌ای (database) استفاده می‌کنند که روی دستگاه اجرا می‌شود و توسط اپلیکیشن راه‌اندازی شده است. هکرها نه تنها می‌توانند محتویات این پایگاه‌های داده را مشاهده کنند، بلکه می‌توانند داده‌ها و شمای (schema) آن را نیز برای اهداف خود تغییر دهند. بنابراین، داده‌های حساس را در پایگاه داده روی دستگاه ذخیره نکنید. کلاینت موبایل (mobile client) باید اعتبارسنجی کند که فیلدها و ردیف‌های داده‌های بازیابی شده از هر پایگاه داده (سمت کلاینت یا سمت سرور) با نوع، اندازه، کمیت و محدوده مقادیر مورد انتظار مطابقت دارند.

دستکاری شبکه‌ها (networks) که از طریق حملات مرد میانی (man-in-the-middle attacks) مورد سوء استفاده قرار می‌گیرد، با استفاده از HTTPS، پین کردن گواهی (certificate pinning)، رمزگذاری سرتاسری (end-to-end encryption) و استفاده از VPNها قابل پیشگیری است. از گواهی‌های خودامضا (self-signed certificates) در اپلیکیشن‌های خود استفاده نکنید، مگر شاید در محیط توسعه.

انکار (Repudiation)

با «ورود به سیستم امن» (secure logging) شناسایی کاربر و اقدامات کاربران مقابله می‌شود، که به نوبه خود نیازمند توابع شناسایی کاربر، احراز هویت و مجوزدهی قوی (solid user identification, authentication and authorization functions) است. استفاده از احراز هویت دو عاملی (2-factor authentication) به طور فزاینده‌ای رایج شده است و این به کنترل دسترسی به اپلیکیشن‌ها کمک می‌کند. بسیاری از اپلیکیشن‌ها و سرویس‌ها از دستگاه موبایل به عنوان عامل دوم برای احراز هویت استفاده می‌کنند. سرویس یک پیام SMS به تلفن ارسال می‌کند که به عنوان مثال، یک توکن ۶ رقمی یک بار مصرف (one-time 6-digit token) را شامل می‌شود و کاربر آن توکن را در اپلیکیشن وارد می‌کند تا هویت کاربر را تأیید کند. اما در فضای اپلیکیشن‌های موبایل، اگر تلفن شما به سرقت رفته باشد و هکر رمز عبور شما را برای ورود به یک اپلیکیشن موبایل بداند، ارسال یک پیام SMS به تلفن سرقت شده هیچ محافظت اضافی ارائه نمی‌دهد. و البته، هکرهای مهندسی اجتماعی (social engineering hackers) نیز روی این عامل دوم تمرکز دارند.

افشای اطلاعات (Information Disclosure)

افشای اطلاعات مربوط به داده‌ها با رمزگذاری در حین انتقال (in transit) و در حافظه (in storage) مقابله می‌شود. اطمینان حاصل کنید که از استانداردهای رمزگذاری فعلی و صنعتی (current, industry-standard encryption standards) استفاده می‌کنید. تمام دستگاه‌های موبایل فعلی از رمزگذاری با AES و با اندازه‌های کلید ۱۲۸ و ۲۵۶ بیت پشتیبانی می‌کنند. اما سپس کلیدهای رمزگذاری باید به دقت محافظت شوند، زیرا یک کلید افشا شده به هکرها اجازه می‌دهد تا داده‌ها را رمزگشایی کنند.

سیستم عامل iOS یک key store برای محافظت از داده‌های حساس دارد. اندروید دارای «API زنجیره‌ی کلید» (Keychain API) است. این کلیدخانه‌ها داده‌ها را به صورت رمزگذاری شده روی دستگاه ذخیره می‌کنند و حتی با دسترسی روت (root access) به دستگاه، سرقت آن اطلاعات را برای هکرها دشوار می‌سازند.

خود نرم‌افزار به راحتی از یک اپلیکیشن موبایل افشا می‌شود. به ویژه اپلیکیشن‌های اندروید که در کاتلین (Kotlin) یا جاوا (Java) نوشته شده‌اند، به راحتی مهندسی معکوس می‌شوند تا کد منبع (source code) زیربنایی خود را آشکار کنند. ابزارهای مبهم‌سازی کد (Code obfuscation tools) را می‌توان برای دشوارتر کردن رمزگشایی کد استفاده کرد.

محرومیت از سرویس (Denial of Service)

حملات «محرومیت از سرویس» معمولاً در سمت سرور (server-side) مشاهده می‌شوند. «بات‌نت‌ها» (Botnets) یک مشکل مداوم هستند، زیرا به سرورها حمله می‌کنند و دسترسی اپلیکیشن‌های موبایل قانونی (legitimate mobile apps) را سلب می‌کنند. یکی از استراتژی‌ها برای کاهش خطر حملات «محرومیت از سرویس» استفاده از یک سرویس ابری تجاری (commercial cloud service) است. همه سرویس‌های ابری دارای محافظت در برابر «محرومیت از سرویس» هستند که در زیرساخت آن‌ها تعبیه شده است، بنابراین می‌توانید بیشتر بر روی عملکرد تجاری اپلیکیشن‌های خود تمرکز کنید.

افزایش سطح دسترسی (Escalation of Privilege)

«افزایش سطح دسترسی» ممکن است در زمینه مدل اتفاق بیفتد که در آن ترافیک شبکه ممکن است هک شود و سطح دسترسی یک کاربر ممکن است افزایش یابد تا به داده‌هایی دسترسی پیدا کند که کاربر نباید آن‌ها را ببیند. این بیشتر یک هک API است تا یک هک اپلیکیشن موبایل به معنای واقعی کلمه. اما خطر همچنان وجود دارد. شما با داشتن نقش‌های (roles) با تعریف خوب که توسط کنترل‌های دسترسی (access controls) اعمال می‌شوند، با خطر «افزایش سطح دسترسی» مقابله می‌کنید: حداقل کردن امتیازات (Minimize privileges) - هرچه نقش‌ها و امتیازات کمتر باشد، اپلیکیشن «سطح حمله» (attack surface) کمتری دارد.

برخی از اپلیکیشن‌های موبایل چیزی بیش از یک آیکون (icon) نیستند که یک وب‌سایت را راه‌اندازی می‌کنند. اگر راه‌حل شما از خدمات وب (web services) و وب‌سایت‌ها استفاده می‌کند، آنگاه «۱۰ مورد برتر برنامه وب OWASP» یک لیست استاندارد از مسائل کلیدی است که باید نگران آن‌ها باشید.

آزمایش امنیت

هنگامی که اپلیکیشن خود را ساختید و تمام آزمایش‌های عملکردی (functional testing) ممکن را انجام دادید، زمان آن فرا رسیده است که یک آزمایش امنیتی (security test) انجام دهید. در حوزه اپلیکیشن‌های موبایل، می‌توانید فایل باینری (IPA یا APK) را به یک تیم آزمایش امنیتی جداگانه تحویل دهید یا خودتان آزمایش را انجام دهید. در اینجا یک چک‌لیست از آزمایش‌های امنیتی که می‌توانید اپلیکیشن خود را در برابر آن‌ها اجرا کنید، آورده شده است. این چک‌لیست به هیچ وجه جامع نیست، اما به شما ایده‌ای از دامنه مسائلی می‌دهد که باید پس از ساخت یک اپلیکیشن و آماده شدن برای آزمایش امنیت آن، بررسی کنید:

1. شناسایی (Identification) - آیا اپلیکیشن شما کاربر اپلیکیشن را به درستی شناسایی می‌کند؟ برخی از اپلیکیشن‌ها، مانند اپلیکیشن چراغ قوه، برای استفاده توسط کاربران ناشناس (anonymous users) طراحی شده‌اند؛ در حالی که برخی دیگر، مانند اپلیکیشن‌های بانکی، نیاز به شناسایی منحصر به فرد هر کاربر دارند.
2. احراز هویت (Authentication) - اگر کاربر نیاز به شناسایی دارد، آیا روش امنی برای احراز هویت دارید تا ثابت کنید کاربر همان کسی است که ادعا می‌کند؟ اطمینان حاصل کنید که هکرها نمی‌توانند فرآیند احراز هویت را دور بزنند. احراز هویت باید در سمت سرور (server-side) انجام شود - در ابر (cloud)، در یک مرکز داده (datacenter)، هر جایی به جز خود دستگاه موبایل، زیرا دستگاه موبایل قابل اعتماد نیست. استفاده از احراز هویت دو عاملی (2-factor authentication) را در نظر بگیرید. ما مدت‌هاست از دوره‌ای که سیستم‌ها می‌توانستند فقط با یک رمز عبور به طور قابل اعتماد ایمن شوند، گذشته‌ایم. هر کسی که در مکان عمومی وارد اپلیکیشن می‌شود، در معرض خطر حمله «شانه به شانه» (shoulder-surf attack) است - جایی که شخصی از شما در حال وارد کردن رمز عبور در اپلیکیشن فیلم می‌گیرد. و حملات فیشینگ (phishing attacks) همچنان در حال افزایش هستند - ایمیل‌ها، پیامک‌ها، سایر پیام‌ها که به شما می‌گویند روی این لینک کلیک کنید و وارد حساب بانکی خود شوید قبل از اینکه بسته شود یا دسیسه دیگری که به احساسات، فوریت یا تهدیدات متوسل می‌شود تا شما را وادار کند با رمز عبور و شناسه معتبر خود وارد یک سرویس جعلی شوید. احراز هویت عامل دوم (second-factor authentication) دسترسی هکرها به حساب‌های شما را تنها با یک رمز عبور سرقت شده دشوارتر می‌کند. اما اگر آن عامل دوم فقط یک پیامک به تلفن سرقت شده شما باشد، هیچ محافظت اضافی وجود ندارد.
3. مجوزدهی (Authorization) - هنگامی که کاربر به درستی شناسایی و احراز هویت شد، آیا او مجوز استفاده از هر سرویسی که شما ارائه می‌دهید را دارد؟ اگر یک سرویس پولی است، باید آزمایش کنید که هکرها نمی‌توانند راهی برای استفاده رایگان از سرویس شما پیدا کنند. توابع مجوزدهی نیز باید در سمت سرور اجرا شوند.
4. پاسخگویی (Accountability) - اگر کاربران بدین ترتیب شناسایی، احراز هویت و مجوزدهی شدند، آیا اپلیکیشن تراکنش‌های مهم (import transactions) را ثبت می‌کند تا هیچ حمله انکار (repudiation attacks) رخ ندهد؟ شما به اندازه کافی اطلاعات ثبت (log information) نیاز دارید، بدون به خطر انداختن حریم خصوصی کاربران، تا اگر یک بازرس دولتی برای دریافت اطلاعات در مورد اینکه چه کسی، چه زمانی و برای چه هدفی از اپلیکیشن شما استفاده کرده است، آمد، بتوانید به او بگویید. و اگر کاربر آمد و درخواست "مرا فراموش کن" (forget me) را داد، می‌توانید تمام داده‌های جمع آوری شده مربوط به آن کاربر را حسابرسی کرده و آن داده‌ها را به طور ایمن حذف کنید.
5. کد اپلیکیشن و امنیت وب (App code and web security) - آیا اپلیکیشن در برابر حملات تزریق (injection attacks) از هر نوع مقاومت می‌کند؟ با پاکسازی ورودی از دامنه‌های نامعتبر (untrusted domains) (در اینجا به مدل تهدید خود مراجعه کنید) در برابر حملات تزریق محافظت کنید. تمام ورودی‌ها را از نظر اندازه، نوع، محدوده مقادیر و مقدار داده‌های مورد انتظار بررسی کنید. آنالیزورهای کد ایستا امن (secure static code analyzers) را برای یافتن مسائل امنیتی ظریف در کد خود اجرا کنید و آنها را برطرف کنید. دو فروشنده پیشرو برای اسکن کد منبع ایستا امن (secure static source code scanning) «چک‌مارکس» (Checkmarx) و «میکروفوکوس فورتیفای» (Microfocus Fortify) هستند. آیا جلسات (sessions) امن هستند، به طوری که APIها بدون احراز هویت مناسب قابل سوءاستفاده نباشند؟ ممکن است لازم باشد از یک ابزار تست نفوذ وب (web pen test tool)، مانند «HCL اپ‌اسکنز» (HCL Appscans) یا نرم‌افزار منبع باز «فورتیفای وب‌اینسپکت» (Fortify WebInspect) استفاده کنید تا مطمئن شوید خدمات بک‌اند شما امن هستند. از ابزارهای مبهم‌سازی کد (code obfuscation tools)، مانند «پروگارد» (ProGuard) برای دشوارتر کردن تحلیل اپلیکیشن خود استفاده کنید.
6. امنیت بسته‌بندی (Packaging security) - مطمئن شوید که هیچ اطلاعات حساسی، مانند اطلاعات محیط آزمایش، رمز عبور، مستندات توسعه‌دهنده (developer documentation) را در بسته اپلیکیشن (app package) قرار نداده‌اید. اگر از کتابخانه‌های شخص ثالث (third party libraries) استفاده می‌کنید، بررسی کنید که از جدیدترین، پچ شده‌ترین و قابل اعتمادترین نسخه‌های آن بسته‌ها استفاده می‌کنید.
7. امنیت داده (Data security) - اگر داده‌ای را به صورت محلی در دستگاه ذخیره می‌کنید، بدانید که توسط کسی با گوشی روت‌شده یا جیل‌بریک‌شده قابل مشاهده یا تغییر است. حتی اگر رمزگذاری شده باشد، اگر کلید رمزگذاری (encryption key) در دستگاه ذخیره شود، هکر را قادر می‌سازد تا آن اطلاعات را سرقت کند. بنابراین، بررسی کنید که هیچ اطلاعات حساسی را در پایگاه‌های داده یا فایل‌ها روی دستگاه ذخیره نکرده‌اید.
8. امنیت حمل و نقل (Transport security) - هنگام اجرای اپلیکیشن، از «وایرشارک» (Wireshark) (wireshark.org) یا یک ابزار پروکسی وب (web proxy tool)، مانند «پاروس» (Paros) (sourceforge.net/projects/paros) یا «چارلز پروکسی» (Charles Proxy) (charlesproxy.com)، برای ضبط ترافیک ورودی و خروجی اپلیکیشن استفاده کنید تا مطمئن شوید تمام اطلاعات حساس به صورت رمزگذاری شده و فقط به سرورهای مورد انتظار منتقل می‌شوند. حتی اطلاعات غیرحساس نیز باید رمزگذاری شوند تا یکپارچگی داده‌ها (integrity of the data) تضمین شود، مبادا هکر محتوای مخرب را به ترافیک شبکه تزریق کند. اگر می‌توانید، از هیچ پروتکل TLS (Transport Layer Security) قدیمی‌تر از TLS 1.2 پشتیبانی نکنید. پروتکل TLS 1.3 (ietf.org/blog/tls13) در آگوست ۲۰۱۸ توسط IETF به عنوان یک استاندارد تأیید شد که امنیت و عملکرد TLS 1.2 را بهبود می‌بخشد. «تست سرور SSL کوالیسیس» (Qualsys SSL Server Test) یک سرویس آنلاین رایگان است که تست امنیتی گواهی TLS را برای هر نام دامنه عمومی (public domain name) در اینترنت انجام می‌دهد. این سرویس اطمینان حاصل می‌کند که گواهی TLS منقضی نشده باشد، دارای یک زنجیره گواهی معتبر (trusted certificate chain) باشد، اکسپلویت‌های (exploits) امنیتی شناخته شده را علامت‌گذاری و شناسایی می‌کند، نشان می‌دهد کدام مجموعه‌های رمزنگاری (cipher suites) امن و کدام ضعیف هستند، و نام دامنه را با نام رایج (common name) روی گواهی مقایسه می‌کند. از این برای تست تمام دامنه‌های HTTPS که اپلیکیشن شما از آنها استفاده می‌کند، به ویژه آنهایی که مربوط به بسته‌های نرم‌افزاری شخص ثالث (3rd-party software packages) هستند - مانند سرویس‌های تبلیغات، معیارهای سنجش (metrics)، رسانه‌های اجتماعی، نقشه‌ها و غیره استفاده کنید. در اپلیکیشن‌های iOS، از تنظیمات «امنیت حمل و نقل اپ» (App Transport Security settings) برای اجبار استفاده از HTTPS در صورت امکان استفاده کنید.
9. امنیت پروتکل (Protocol security) – مطمئن شوید که پروتکل‌های ورود و خروج (login and logout protocols) به درستی کار می‌کنند و قابل دور زدن نیستند. توابع خروج (Logout functions) باید تراکنش‌ها را به سرور ارسال کنند تا هرگونه جلسه امن (secure sessions) را ببندند – فقط به صفحه ورود به سیستم اپلیکیشن برنگردید. بررسی کنید که توابع بازنشانی رمز عبور (password reset functions) به راحتی قابل جعل نباشند. یک سیاست رمز عبور (password policy) تعیین کنید که رمز عبورهای پیچیده را الزامی کند.
10. حریم خصوصی (Privacy) – مطمئن شوید که می‌دانید چه داده‌هایی در مورد کاربران شما جمع‌آوری می‌شود. آن داده‌ها را برای کاهش ریسک به حداقل برسانید. آیا به کاربر اطلاع‌رسانی حریم خصوصی (privacy notice) ارائه می‌دهید؟ آیا قابلیت‌های "مرا فراموش کن" (forget me) را برای برآورده کردن الزامات حریم خصوصی GDPR (مقررات عمومی حفاظت از داده‌ها) در آن تعبیه کرده‌اید؟

برآوردن الزامات حریم خصوصی

اکثر موارد بالا بر قفل کردن اپلیکیشن شما متمرکز هستند، به طوری که اطلاعات از طریق نظارت غیرفعال (passive surveillance) یا نفوذ فعال (active intrusion) به بیرون درز نکند. اما مقررات حریم خصوصی فعلی، مانند GDPR، نیازمند قابلیت "فراموش شدن" (to be forgotten) است، یعنی حذف ایمن داده‌های کاربر در سیستم، تضمین حق کاربر برای دسترسی به داده‌های خود، و اطلاع رسانی سریع در مورد نقض (breach). و همه اینها باید "غیرقابل نفوذ" (watertight) باشند. اکثر محصولات برای جمع‌آوری اطلاعات طراحی شده‌اند و معمولاً راهی ایمن برای حذف داده‌ها از سیستم ندارند، مگر اینکه به مدیر پایگاه داده و تیکت پشتیبانی برای تلاش برای حذف داده‌های یک نفر تکیه کنند. جریمه‌های عدم رعایت (non-compliance) می‌تواند سرسام‌آور باشد، و برد آن جهانی است - هر کجا که داده‌های شهروند اتحادیه اروپا پردازش می‌شود، GDPR اعمال می‌شود. رضایت (Consent) باید به زبانی واضح و ساده توضیح داده شود و پس گرفتن رضایت باید به همان آسانی دادن آن باشد. بنابراین اپلیکیشن‌های موبایل نه تنها باید از نظر امنیتی از نظر فنی عالی باشند، بلکه باید ابزارهای مدیریت داده (data management tools) موثری - سمت سرور و/یا سمت موبایل - را برای رعایت GDPR که خود به تنهایی یک منظومه شمسی از قوانین و مقررات حریم خصوصی است، پیاده‌سازی کنند.

ایالت کالیفرنیا قوانین حریم خصوصی خاص خود را دارد، «قانون حریم خصوصی مصرف‌کننده کالیفرنیا» (California Consumer Privacy Act)، که از ۱ ژانویه ۲۰۲۰ به اجرا در می‌آید. سایر ایالت‌های ایالات متحده نیز در حال بررسی قوانین حریم خصوصی خود هستند. مطمئن شوید که از آنها مطلع باشید.

بیشتر بیاموزید

در اینجا برخی منابع و مراجع مفید آورده شده‌اند که ممکن است به شما کمک کنند:

• اپل (Apple) راهنمایی کلی برای امنیت نرم‌افزار ارائه می‌دهد. این راهنما همچنین شامل چندین لینک به موضوعات دقیق‌تر برای پلتفرم آنها است.
• دوره‌های آموزشی تجاری (Commercial training courses) برای iOS و اندروید در دسترس هستند. «موسسه لنسلوت» (Lancelot Institute) (lancelotinstitute.com) دوره‌های کدنویسی امن (secure coding courses) را برای iOS و اندروید ارائه می‌دهد.
• یک تست‌کننده SSL رایگان (free SSL tester) توسط «آزمایشگاه‌های کوالیسیس» (Qualsys Labs) ارائه شده است.
• راهنمایی‌های گسترده در زمینه امنیت اپلیکیشن (application security guidance) و ابزارهای آزمایش (testing tools) توسط OWASP ارائه شده است، از جمله «پروژه امنیت موبایل OWASP».

سخن آخر (The Bottom Line)

کهکشان اپلیکیشن‌های موبایل به طور فزاینده‌ای با جهان در حال گسترش خدمات ابری، دستگاه‌های IoT و پلتفرم‌های جدید و عجیب در هم تنیده شده است. اکنون بیش از هر زمان دیگری، این اپلیکیشن‌ها در معرض خطر کسانی هستند که می‌خواهند از آنها به صورت مخرب استفاده کنند، داده‌ها را از آنها سرقت کنند، داده‌ها را برای باج‌گیری نگه دارند، یا به سرویس‌ها و دستگاه‌های متصل حمله کنند. سطح مناسب امنیت اپلیکیشن (application security) چیزی است که باید به صورت سرتاسری (end-to-end) در نظر گرفته شود. در نهایت، اپلیکیشن شما و زیرساخت بک‌اند (backend infrastructure) و نقاط پایانی (endpoints) آن به حال خود رها خواهند شد و باید از خود در برابر هکرها و سایر تهدیدات مخرب دفاع کنند.

زمان را برای یادگیری ویژگی‌های امنیتی و قابلیت‌های پلتفرم‌های موبایلی که قصد هدف قرار دادن آنها را دارید، اختصاص دهید. از تکنیک‌هایی مانند مدل‌سازی تهدید (threat modeling) برای شناسایی تهدیدات احتمالی مرتبط با اپلیکیشن خود استفاده کنید. بررسی کد (code reviews) را انجام دهید و روش‌های ثبت و اشکال‌زدایی (logging and debugging methods) غیرضروری را حذف کنید. یک ابزار تحلیل کد امن (secure code analysis tool) را روی کد موبایل خود اجرا کنید تا آسیب‌پذیری‌ها (vulnerabilities) را پیدا کنید. در نظر بگیرید که یک هکر چگونه کد شما را تحلیل می‌کند، سپس از تکنیک‌های مشابه، در یک محیط امن، در برابر اپلیکیشن خود استفاده کنید تا آسیب‌پذیری‌ها را کشف کرده و قبل از انتشار اپلیکیشن خود، این آسیب‌پذیری‌ها را کاهش دهید.

خدمات و شرکای قابل اعتماد (trustworthy services and partners) را انتخاب کنید. اغلب ما برای خدمت‌رسانی به کاربران و ذینفعان خود به اشخاص ثالث (third-parties) متکی هستیم. رویکردهای آنها در مورد حریم خصوصی و همچنین رویه‌های آنها اهمیت دارد. استفاده از شرکت‌هایی که خود را به استانداردهای بالا ملزم می‌دانند و در مورد کارهایی که انجام می‌دهند - و انجام نمی‌دهند - شفاف هستند، می‌تواند به ما در محافظت از کاربران و ذینفعانمان کمک کند. و زمان را برای در نظر گرفتن پیامدهای حریم خصوصی برای هر داده‌ای که در مورد کاربر یا از طرف او جمع‌آوری می‌کنید، به ویژه اگر آن داده‌ها را در ابر ذخیره یا همگام‌سازی می‌کنید، اختصاص دهید.