主机基线不是一份通用配置清单，而是把“谁能登录、操作如何留痕、密钥怎样保管”落实到每台服务器。制定非洲金融科技应用主机安全基线制定方案时，应先区分生产、测试和运维主机，再按风险设定权限、日志与密钥要求。非洲各国的监管和数据保护规则并不相同，部署前还需由当地法律与合规团队确认适用要求。
先划定主机范围与责任
建立资产清单，记录主机用途、环境、负责人、系统版本、所在云区域或机房，以及是否处理支付凭证、身份资料或交易记录。将互联网入口、应用节点、批处理节点和管理跳板机分开管理；开发测试环境不得默认继承生产权限。主机新增、用途改变或退役时，都应同步更新清单和基线状态。
基线至少明确三个责任人：系统负责人维护配置，安全人员复核访问与告警，业务负责人批准生产权限。对网络连通性不稳定或跨境协作较多的团队，应准备受控的应急登录流程，而非长期保留共享账号或无人看管的远程入口。
权限：从个人身份到最小授权
账号与提权
为每名运维人员建立个人账号，禁用默认账号和不必要的交互式登录；日常工作不使用 root。通过 sudo 按命令或职责授予短时提权，并要求多因素认证用于管理入口。离职、岗位变更和供应商任务结束时，及时撤销账号、SSH 公钥及相关令牌。
- 盘点本地账号、服务账号、SSH 公钥和自动化凭据，标出所有者与用途。
- 删除无主或闲置身份；确需保留的服务账号应禁止交互登录，并限制可访问的目录、服务和主机范围。
- 将生产权限按工单或变更任务申请，设定到期时间；紧急访问使用单独审批和事后复核。
- 每月至少检查一次高权限成员；其他账号的复核频率可按风险设为每季度或更短，并记录处理结果。
不要把“能登录服务器”与“能读取客户数据”视为同一权限。应用进程应以专用系统用户运行，只能访问必要文件和服务。这样即使应用进程被利用，也能限制其对其他组件的影响。
日志：让事件可追溯、可调查
审计日志应覆盖登录成功与失败、sudo 提权、账号和权限变更、关键配置修改、服务启停、系统时间变化，以及安全代理或日志服务停止。Linux 主机可使用 auditd 记录关键系统操作，并由集中日志平台接收；systemd-journald 可作为本机服务日志来源，但不应是唯一留存位置。
传输、告警与留存
集中日志应限制读取和删除权限，主机到日志平台的传输需认证并加密。监控异常登录暴增、非工作时段提权、审计服务中断和日志容量不足。可将近线日志保留约30至90天作为运维排查起点，再把归档期限交由业务风险及当地法规确定；这不是所有国家或业务都适用的统一期限。定期抽查主机时间同步、日志字段完整性与告警送达情况，避免只“收集”却无法检索。
密钥：不落盘、可轮换、可撤销
把密钥与口令视为不同于普通配置的敏感资产。优先使用云密钥管理服务或 HashiCorp Vault 等集中式密钥管理工具；具体选择取决于云环境、运维能力、可用性和数据驻留要求。应用只在运行时获取所需凭据，避免写入镜像、代码仓库、命令行参数或普通日志。主机本地配置文件如确实不可避免，应限制属主与读取权限，并纳入加密备份和访问审计。
- 为每个密钥登记用途、责任人、创建日期、依赖服务和撤销步骤。
- 区分加密密钥、数据库凭据、签名密钥和运维 SSH 凭据，避免多系统共用。
- 依据暴露风险、算法与业务影响设定轮换周期；发现泄漏、人员离职或权限边界变化时立即轮换或撤销。
- 轮换前验证新旧凭据切换流程，并保留回滚方案；撤销后检查缓存、备份和自动化任务是否仍引用旧值。
密钥备份应受独立权限保护，并通过恢复演练确认可用。若密钥管理服务暂时不可达，应采用经过审批的降级机制，不能把长期明文副本作为可用性方案。
落地顺序与常见问题
建议先在一组非生产主机试行：生成基线、自动检查配置偏差、修复高风险项，再扩展到生产。每次变更保留负责人、时间、理由和验证结果。衡量效果时关注无主账号数量、特权账号复核完成率、日志接收中断时长和密钥轮换失败情况，而不只看安装了多少安全工具。最终，非洲金融科技应用主机安全基线制定应形成可复核的配置、权限审批、日志告警和密钥处置流程，并依据实际部署国家与服务风险持续更新。
常见问题
- 生产主机能否共用运维账号？
不建议。个人身份便于追责；自动化任务使用独立服务账号，并限制权限和登录方式。
- 日志需要保存多久？
先满足排障和调查需要，再核对当地法规、合同及业务风险；30至90天可作为在线排查的起点，不应替代合规评估。
- 密钥多久轮换一次？
没有适用于所有密钥的固定周期。按用途、暴露风险和业务切换能力设定，并在疑似泄漏时立即处置。
- 网络中断时如何保障运维？
预先定义限时、审批、留痕的应急访问方式；恢复连接后复核操作记录并撤销临时权限。
