4. 安全审计基础
在 Android 系统安全审计中，审计不是“随手翻日志”，而是一项有目标、有边界、有标准、有证据闭环的系统性活动。它既要回答“系统是否按预期安全运行”，也要回答“一旦发生异常，能否还原事实、定位责任、支撑整改与合规”。因此，理解审计目标、范围、标准、流程、证据链与合规要求，是后续故障定位与安全分析的基础。
一、审计目标：从“看见”到“可证明”
Android 安全审计的核心目标可归纳为四个层次：可见性、可追溯性、可验证性与可合规性。可见性要求关键安全事件（如应用安装、权限授予、SELinux 拒绝、root 提权、密钥使用）必须被记录；可追溯性要求每条记录能关联到具体进程、UID、时间、设备与操作上下文；可验证性要求日志与系统状态、文件哈希、签名信息相互印证；可合规性则要求审计活动满足等保、GDPR、ISO 27001 或企业内控要求。
在 Android 场景中，审计目标通常聚焦于：应用行为审计、权限与访问控制审计、系统完整性审计、数据泄露风险审计以及设备管理合规审计。不同目标决定了后续采集哪些日志、保留多久、以何种粒度分析。
二、审计范围：明确边界，避免“全量即无效”
审计范围包括对象范围、时间范围、数据范围与责任范围。对象范围可覆盖应用层、框架层、Native 层、内核层与硬件抽象层；时间范围决定日志保留窗口与取证回溯深度；数据范围涉及 logcat、dmesg、auditd、EventLog、DropBox、tomstone、ANR trace、SELinux AVC 等；责任范围则明确谁采集、谁分析、谁复核、谁整改。
三、审计标准与合规要求
Android 安全审计需同时参考技术标准与合规框架。技术侧常用标准包括 Android CDD/CTS、SELinux 策略规范、Keystore/KeyMint 要求、AVB 验证启动规范；合规侧包括等保 2.0 的审计要求、ISO 27001 的日志与监控控制、GDPR 的数据最小化与可追溯要求。审计标准决定了“什么算合格”，合规要求决定了“什么必须留痕”。
| 维度 | 关键要求 | Android 落地示例 |
|---|---|---|
| 完整性 | 日志不可篡改、可校验 | AVB 校验启动链、日志哈希链 |
| 可追溯 | 事件关联 UID/PID/时间 | auditd 记录 syscall 与 SELinux 上下文 |
| 最小化 | 仅采集必要数据 | 避免采集用户隐私内容，仅保留元数据 |
| 保留期 | 满足法规与内控周期 | 安全日志保留 6 个月以上 |
| 可复核 | 双人复核、操作留痕 | 审计报告与原始日志分离存储 |
四、审计流程与证据链
标准审计流程通常为：计划 → 采集 → 解析 → 分析 → 取证 → 报告 → 整改 → 复核。其中证据链是审计的灵魂：从原始日志到分析结论，每一步都要有来源、时间、工具、操作人和校验值。Android 中常见证据包括 logcat 缓冲区、auditd 日志、SELinux AVC 拒绝记录、tomstone 崩溃栈、包签名信息与文件哈希。
# 采集 Android 安全审计关键证据示例
adb shell dmesg > dmesg.log
adb shell logcat -b all -d > logcat_all.log
adb shell cat /sys/fs/selinux/avc > avc.log
adb shell dumpsys package com.example.app > package_dump.txt
adb shell sha256sum /system/bin/app_process > hash.txt
证据链要求“原始证据不可变、分析过程可复现、结论可回溯”。建议对采集文件计算 SHA-256 并记录采集时间、设备序列号、Android 版本与安全补丁级别。若证据链断裂，审计结论在合规审查或故障定责中往往不被采信。
五、典型场景与误区复盘
场景一：某应用频繁触发 SELinux 拒绝，审计人员仅查看 logcat 未采集 auditd，导致无法确认是策略缺失还是应用越权。正确做法是同时采集 dmesg、auditd 与 avc 记录，并关联进程上下文。
场景二：合规检查要求提供“权限变更审计”，但团队只保留了应用层日志，缺少 PackageManager 的安装与权限授予记录，导致证据链不完整。应在审计范围中明确系统服务日志的采集点。
复盘时应重点检查：审计目标是否可度量、范围是否覆盖关键层、标准是否明确、流程是否闭环、证据链是否完整、合规输出是否可复核。只有把“目标—范围—标准—流程—证据链—合规”串成一条线，Android 安全审计才能真正支撑系统安全与故障定位。