移动 Android安全机制，APP安全防护，平台安全(企业安全体系)_android安全防护防护 android数据加密 原理

Android安全- http://blog.csdn.net/SEU_Calvin/article/category/6308670
理解Android安全机制- https://blog.csdn.net/ff673551532/article/details/73002333
APP安全（二）终端安全全预览- https://tamicer.github.io/2017/03/02/safeinfoall/
Android安全研究经验谈- http://www.cnblogs.com/whp2011/archive/2015/01/26/4250875.html
> Android 安全性
  Android 安全性话题,涵盖了存储数据、权限、网络、处理凭据、输入验证、处理用户数据、加密等。对App进行加固，可以有效防止移动应用被破解、盗版、二次打包、注入、反编译等，保障程序的安全性、稳定性。代码混淆、防止逆向工程。
  目前关于Android APK的安全性是非常令人堪忧的。APK运行环境依赖的文件/文件夹 res、DEX、主配文件Lib 只是简单的加密甚至没有任何加密措施。APKtool工具可轻易将其破解，再配合其他各种工具基本可以做到：源码暴露(代码混淆也几乎起不到任何安全作用)、资源文件裸奔、主配文件可任意修改、核心SO库暴露、暴力破解恶意利用等。部分大公司会对其应用APK包进行防二次打包和防APKtool破解，但其代码都是写在JAVA层，另外APKtool的可升级导致其安全保护级别也是非常低的。

-- Android应用面临哪些安全问题呢？
  病毒；关键信息泄露；APP重打包；进程被劫持；数据在传输过程遭劫持；Webview漏洞；
  病毒不用多说了，都是一些恶意软件。关键信息泄露，可能有些开发者并不十分留意。虽然Java代码可以做混淆，但是Android的几大组件的创建方式是依赖注入的方式，因此不能被混淆。而且目前常用的一些反编译工具比如apktool等能够毫不费劲地还原Java里的明文信息，native里的库信息也可以通过objdump或IDA获取。因此一旦Java或native代码里存在明文敏感信息，基本上就是毫无安全而言的。重打包即通过反编译后重新加入恶意的代码逻辑，重新打包一个APK文件。进程被劫持一般通过进程注入或者调试进程的方式来hook进程，改变程序运行的逻辑和顺序，从而获取程序运行的内存信息。hook需要获取root权限或者跟被hook进程相同的权限。如果手机没被root，被劫持的可能性还是较小。数据在传输过程遭劫持，一般来说是由于数据明文传输或没使用HTTPS。Webview漏洞一般由于JS注入。

  Android 密钥保护和 C/S 网络传输安全 .这一方面，Android 提供大量用来保护数据的加密算法，例如 Cipher 类中提供了 AES 和 RSA 算法，再例如安全随机数生成器 SecureRandom 给 KeyGenerator 提供了更加可靠的初始化参数，避免离线攻击等等。
 360烽火实验室，致力于Android病毒分析、移动黑产研究、移动威胁预警以及Android漏洞挖掘等移动安全领域及Android安全生态的深度研究。
 谷歌从7.0开始加固了内核。

> Android安全机制
  Android以Linux操作系统内核为基础，实现硬件设备驱动、进程和内存管理、网络协议栈、电源管理等核心系统功能。除此以外，Android还增加了一些面向移动设备的特有功能，如低内存管理LMK(Low Memory Killer)、匿名共享内存(Ashmem: Anonymous Shared Memory)，以及进程间通信Binder机制。这些功能的增强进一步提升了Android在内存管理、进程间通信等方面的安全性。
  在Android 4.3之前的版本，系统在应用程序安装时为每一个应用程序创建一个独立的uid，基于uid来控制访问进程来访问资源，这种安全模型是基于Linux传统的安全模型DAC(Discretionary Access Control，翻译为自主访问控制)来实现的。从Android 4.3开始，安全增强型Linux (SElinux)用于进一步定义应用程序沙箱的界限。作为Android安全模型的一部分，Android使用SELinux的强制访问控制(MAC) 来管理所有的进程，即使是进程具有root(超级用户权限)的能力，SELinux通过创建自动话的安全策略(sepolicy)来限制特权进程来增强 Android的安全性。从Android 4.4开始Android打开了SELinux的Enforcing模式，使其工作在默认的AOSP代码库定义的安全策略(sepolicy)下。在 Enforcing模式下，违反SELinux安全策略的的行为都会被阻止，所有不合法的访问都会记录在dmesg和logcat中。

-- Android内核安全机制：文件访问控制机制，进程隔离与保护机制，内存管理机制等
 在 Linux 基础上， Android 系统对内存管理机制进行了增强， 增加了两个处理机制： Ashmem 机制和 LowMemoryKiller 机制。 Ashmem 机制解决了共享内存的释放问题， LowMemoryKiller 则是一种对内存资源进行强行释放的机制。Ashmem 基于mmap系统调用，不同进程可以将同一段物理内存映射到各自的虚拟地址控制，从而实现共享。Ashmem 提供了内存回收算法机制， 即 pin/unpin 机制。 当不需要使用内存时，就可以将这个没存upin，从而增加了内存的使用率。

-- 在Android系统的应用层中，提供了如下两个安全机制模型：
1.使用显示定义，经用户授权的应用权限控制机制。系统规范并强制各类应用程序的行为准则与权限许可。
2.提供了应用程序的签名机制，实现了应用程序之间的信息信任和资源共享。

-- Android安全模型主要提供以下几种安全机制：
进程沙箱隔离机制；应用程序签名机制；权限声明机制；访问控制机制；进程通信机制；内存管理机制等。
　1.进程沙箱隔离机制，使得Android应用程序在安装时被赋予独特的用户标识（UID），并永久保持。应用程序及其运行的Dalvik虚拟机运行在独立的Linux进程空间，与其它应用程序完全隔离。在特殊情况下，进程间还可以存在相互信任关系。如源自同一开发者或同一开发机构的应用程序，通过Android提供的共享UID（Shared UserId）机制，使得具备信任关系的应用程序可以运行在同一进程空间。
  2.应用程序签名机制，规定APK文件必须被开发者进行数字签名，以便标识应用程序作者和在应用程序之间的信任关系。在安装应用程序APK时，系统安装程序首先检查APK是否被签名，有签名才能安装。当应用程序升级时，需要检查新版应用的数字签名与已安装的应用程序的签名是否相同，否则，会被当做一个新的应用程序。Android开发者有可能把安装包命名为相同的名字，通过不同的签名可以把他们区分开来，也保证签名不同的包不被替换，同时防止恶意软件替换安装的应用。
  3.权限声明机制，要想获得在对象上进行操作，就需要把权限和此对象的操作进行绑定。不同级别要求应用程序行使权限的认证方式也不一样，Normal级申请就可以使用，Dangerous级需要安装时由用户确认，Signature和Signatureorsystem级则必须是系统用户才可用。
  4.访问控制机制，确保系统文件和用户数据不受非法访问。
  5.进程通信机制，基于共享内存的Binder实现，提供轻量级的远程进程调用（RPC）。通过接口描述语言（AIDL）定义接口与交换数据的类型，确保进程间通信的数据不会溢出越界。
  6.内存管理机制，基于Linux的低内存管理机制，设计实现了独特的LMK，将进程重要性分级、分组，当内存不足时，自动清理级别进程所占用的内存空间。同时，引入的Ashmem内存机制，使得Android具备清理不再使用共享内存区域的能力。

-- Android应用沙箱 应用沙箱和权限隔离;
  “沙箱”机制sharedUserId和签名;APK 沙箱技术在平台型 App 中的架构实战。沙箱，对使用者来说可以理解为一种安全环境，对恶意访问者来说是一种限制。
   在Android系统中，应用（通常）都在一个独立的沙箱中运行，即每一个Android应用程序都在它自己的进程中运行，都拥有一个独立的Dalvik虚拟机实例。Dalvik经过优化，允许在有限的内存中同时高效地运行多个虚拟机的实例，并且每一个Dalvik应用作为一个独立的Linux进程执行。Android这种基于Linux的进程“沙箱”机制，是整个安全设计的基础之一。
   Android从Linux继承了已经深入人心的类Unix进程隔离机制与最小权限原则，同时结合移动终端的具体应用特点，进行了许多有益的改进与提升。
   Android沙箱的核心机制基于以下几个概念：标准的Linux进程隔离、大多数进程拥有唯一的用户ID（UID），以及严格限制文件系统权限。
   Android系统提供一种所谓共享UID（SharedUserID）机制，使具备信任关系的应用程序可以运行于同一进程空间。通常 ，这种信任关系由应用程序的数字签名确定，并且需要应用程序在manifest文件中使用相同的UID。

-- Android恶意程序沙箱分析,
  Android sandbox 通过利用开源工具动态分析、静态分析android的相关应用，发现应用的具体行为，从而进行判断android应用的危险程度:(http://blog.csdn.net/jiayanhui2877/article/details/8120533)
1、droidbox是基于TaintDroid系统构建的Sandbox，通过hook系统api对apk程序进行监控，随着android SDK的不断更新，其也要随之适配。
  droidbox: http://code.google.com/p/droidbox/
  taintbox: http://appanalysis.org/
2、Apimonitor
  Apimonitor: http://code.google.com/p/droidbox/wiki/APIMonitor
3、AndroGuard
 通过分析主要应用于android应用的静态分析
 AndroGuard: http://code.google.com/p/androguard/

-- SE Android系统

-- 目前SE Android系统中的策略机制主要有三种：
安装时MAC（install-time MAC）；权限取消（permission revocation）；权限标签传播（tag propagation）；
-- SE Android
  Linux将文件的权限划分为读、写和执行三种，分别用字母r、w和x表示。每一个文件有三组读、写和执行权限，分别针对文件的所有者、文件所有者所属的组以及除了所有者以及在所有者所属组的用户之外所有其它用户。这样，如果一个用户想要将一个自己创建的文件交给另外一个用户访问，那么只需要相应地设置一下这个文件的其它用户权限位就可以了。所以，在Linux系统中，文件的权限控制在所有者的手中。因此，这种权限控制方式就称为自主式的，正式的英文名称为Discretionary Access Control，简称为DAC。
  后来，Linux内核采用了必要的访问控制机制：SE Linux（Security-Enhanced Linux），它采用了一种强制存取控制MAC（Mandatory Access Control）策略的实现方式，目的在于通过限制系统中的任何进程以及用户对资源的访问，保护内核安全。而SE Android（Security-Enhanced Android）是Android与SE Linux的结合，由美国NSA在2012年推出的Android操作系统安全强化套件，以支持在Android平台上使用SE Linux。
  SEAndroid是一种基于安全策略的MAC安全机制。这种安全策略又是建立在对象的安全上下文的基础上的。这里所说的对象分为两种类型，一种称主体（Subject），一种称为客体（Object）。主体通常就是指进程，而客观就是指进程所要访问的资源，例如文件、系统属性等。

 -- Android 系统中的UID、GID、GIDS与PID
  在 Android 上，一个用户 UID 标示一个应用程序。应用程序在安装时被分配用户 UID，应用程序在设备上的存续期间内，用户 UID 保持不变。对于普通的应用程序，GID即等于UID。
  GIDS 是由框架在 Application 安装过程中生成，与 Application 申请的具体权限相关。 如果 Application 申请的相应的 permission 被 granted ，而且有对应的GIDS， 那么 这个Application 的 gids 中将 包含这个 gids。记住权限(GIDS)是关于允许或限制应用程序（而不是用户）访问设备资源。
  Android 使用沙箱的概念来实现应用程序之间的分离和权限，以允许或拒绝一个应用程序访问设备的资源，比如说文件和目录、网络、传感器和 API。为此，Android 使用一些 Linux 实用工具（比如说进程级别的安全性、与应用程序相关的用户和组 ID，以及权限），来实现应用程序被允许执行的操作。
  在 Android 上，一个应用程序只有一个UID，当然多个应用程序也可以共享一个UID。
  对 于普通应用程序来说， gid 等于 uid 。由于每个应用程序的 uid 和 gid 都不相同， 因此不管是 native 层还是 java 层都能够达到保护私有数据的作用 。
  一个GIDS相当于一个权限的集合，一个UID可以关联GIDS，表明该UID拥有多种权限.
  一个进程就是host应用程序的沙箱，里面一般有一个UID和多个GIDS，每个进程只能访问UID的权限范围内的文件和GIDs所允许访问的接口，构成了Android最基本的安全基础。

-- SELinux系统

-- SELinux 拥有三个主要的操作模式
• Disabled：禁用SELinux策略
• Permissive：在Permissive模式下，SELinux会被启用但不会实施安全性策略，而仅仅会发出警告及记录行动。Permissive模式在排除SELinux的问题时非常实用
• Enforcing：这个缺省模式会在系统上启用并实施SELinux的安全性策略。拒绝訪问及记录行动

-- SELinux 拥有三种訪问控制方法：
• 强制类型（TE）：TE是针对型策略所採用的主要訪问控制机制
• 基于角色的訪问控制（RBAC）：它以SELinux用户（未必等同Linux用户）为基础。但缺省的针对型策略并未采用它
• 多层保障（MLS）：未被採用，并且常常隐藏在缺省的针对型策略内。

-- 以SELinux文件系统接口为边界，SEAndroid安全机制包含有内核空间和用户空间两部分支持。在内核空间，主要涉及到一个称为SELinux LSM的模块，这个模块包含有一个访问向量缓冲（Access Vector Cache）和一个安全服务（Security Server）。Security Server负责安全访问控制逻辑，即由它来决定一个主体访问一个客体是否是合法的。而在用户空间中，涉及到安全上下文（Security Context）、安全策略（SEAndroid Policy）和安全服务（Security Server）等模块。这些内核空间模块和用户空间模块的作用以及交互如下所示：
 1. 内核空间的SELinux LSM模块负责内核资源的安全访问控制。
 2. 用户空间的SEAndroid Policy描述的是资源安全访问策略。系统在启动的时候，用户空间的Security Server需要将这些安全访问策略加载内核空间的SELinux LSM模块中去。这是通过SELinux文件系统接口实现的。
 3. 用户空间的Security Context描述的是资源安全上下文。SEAndroid的安全访问策略就是在资源的安全上下文基础上实现的。
 4. 用户空间的Security Server一方面需要到用户空间的Security Context去检索对象的安全上下文，另一方面也需要到内核空间去操作对象的安全上下文。
 5. 用户空间的selinux库封装了对SELinux文件系统接口的读写操作。用户空间的Security Server访问内核空间的SELinux LSM模块时，都是间接地通过selinux进行的。这样可以将对SELinux文件系统接口的读写操作封装成更有意义的函数调用。
 6. 用户空间的Security Server到用户空间的Security Context去检索对象的安全上下文时，同样也是通过selinux库来进行的。

-- DAC和MAC的区别：
  1.DAC核心思想：进程理论上所拥有的权限与执行它的用户的权限相同。比如，以root用户启动Browser，那么Browser就有root用户的权限，在Linux系统上能干任何事情。
  2.MAC核心思想：即任何进程想在SELinux系统中干任何事情，都必须先在安全策略配置文件中赋予权限。凡是没有出现在安全策略配置文件中的权限，进程就没有该权限。

-- linux中的用户（UID）、组（GID）、进程（PID)
 Linux系统中的用户(UID)分为3类，即普通用户、根用户、系统用户。每个进程都拥有真实的用户、组（uid、gid），有效的用户、组（euid、egid），保存的设置用户、组（suid、sgid），还有linux中专门用于文件存储存取的用户、组id（fsuid、fsgid对于unix系统没有这两个fields）。

> APP安全防护 ， 代码安全、数据安全
美柚：女性移动APP安全攻防战- https://yq.aliyun.com/articles/61710#
关于Android应用开发的一些安全注意事项- https://blog.csdn.net/t12x3456/article/details/28724571
Android应用安全开发之浅谈加密算法的坑- https://www.cnblogs.com/alisecurity/p/5312083.html
安卓开发,关于代码安全的注意点- https://blog.csdn.net/qq_16471893/article/details/53066329
android 开发之安全问题- https://blog.csdn.net/xiaoyunchengzhu/article/details/53462756
Android安全防护- https://blog.csdn.net/u013409903/article/details/76686155
Android安全研究经验谈- https://www.csdn.net/article/2015-05-27/2824780

Android移动安全开源项目汇总- https://blog.csdn.net/akria1990/article/details/62037120

- 安卓应用在开发过程中有很多安全保护的方案,简单说几种：
 1.使用混淆保护,对APK代码进行基础的防护。
 2.使用伪加密保护方式，通过java代码对APK(压缩文件)进行伪加密，其修改原理是修改连续4位字节标记为”PK0102”的后第5位字节，奇数表示不加密偶数表示加密。伪加密后的APK不但可以防止PC端对它的解压和查看也同样能防止反编译工具编译。
 3.通过标志尾添加其他数据从而防止PC工具解压反编译，这样处理后把APK看做压缩文件的PC端来说这个文件被破坏了，所以你要对其进行解压或者查看都会提示文件已损坏，用反编译工具也会提示文件已损坏，但是它却不会影响在Android系统里面的正常运行和安装而且也能兼容到所有系统 
 4.验证签名信息,通过本地或网络对签名的信息进行验证。
  Android5.0,在涉及用户隐私的Acitivity中（例如登录，支付等其他输入敏感信息的界面中）增加WindowManager.LayoutParams.FLAG_SECURE属性，该属性能防止屏幕被截图和录制。

-- 从以下几个方面来应对Android开发的常见安全问题：
 1.应用权限控制。通过控制应用程序的权限防止恶意应用对系统造成破坏，采取的措施包括合理使用系统内置权限和应用程序自定义权限。
 2.应用程序签名。采用数字签名为应用程序签名。
 3.应用加固。应用加固包括病毒扫描、防注入、防调试、防篡改四个模块，目前行业内已经出现了很多的应用加固解决方案，如360应用加固、腾讯云应用加固、百度应用加固等等。 
 4.静态代码分析。通过静态代码分析工具lint监测安全隐患，对代码进行优化。
 5.防火墙。必要时为Android设备安装防火墙，以防止远程网络攻击。
 6.数据存储加密。采用加密的方式保护应用程序敏感数据，如利用SQLCipher加密SQLite数据库。
 7.应用程序组件开发的安全要点。Activity, Service, Content Provider, Broadcast Receiver等组件在代码层面应采取的安全措施。它们每一个都可以通过隐式的Intent方式打开，所以这些组件只要不是对外公开的必须在AndroidManifest里面注明exported为false，禁止其它程序访问我们的组件。对于要和外部交互的组件，应当添加访问权限的控制，还需要要对传递的数据进行安全的校验。

-- APP几个安全防护措施：
 1.AndroidManifest中的android:allowBackup属性，默认为true，如无特殊情况，可以改为false，防止数据被备份。
 2.防截屏在登录和注册，或修改密码等敏感数据操作时，如果手机中有后台默认隐藏截屏的应用，在输入是一直截屏，就有可能盗取敏感数据信息。解决方案：在Activity onCreate 中加入：
getWindow().addFlags(WindowManager.LayoutParams.FLAG_SECURE);
 3. 本地数据加密,自己进行数据加密;通过第三方进行加密Secure, simple key-value storage for Android- https://github.com/orhanobut/hawk
 4. 隐藏日志
先在当前Module下的build.gradle中的buildTypes方法中代码至如下(之前自己的配置代码不变)：
buildTypes {
    release {
        buildConfigField "boolean", "LOG_DEBUG", "false"
        proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
    }
}
然后在proguard-rules.pro文件中加入：
-assumenosideeffects class android.util.Log{
    public static boolean isLoggable(java.lang.String, int);
    public static int v(...);
    public static int i(...);
    public static int w(...);
    public static int d(...);
    public static int e(...);
}
至此，可以完全隐藏android.util.Log的所有日志。
 5. 混淆
先在当前Module下的build.gradle中的buildTypes方法中修改代码至如下(之前自己的配置代码不变)：
buildTypes {
    release {
        minifyEnabled true
    }
}

> 企业安全
  Google的安全体系给人的感觉是跟基础设施深度融合，完全内置于产品设计和研发过程之中，从顶层设计的视角看完全是两种流派：内置的安全机制vs外挂的防护体系。
 从Google白皮书看企业安全最佳实践- http://tech.meituan.com/GoogleSecurity_ayazero.html?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io?ref=myread