行业经验 · FINANCIAL SERVICES
金融机构的基础平台长期运行，
架构变化必须同时满足连续性与可审计性
金融机构的IT项目往往由平台生命周期、云服务引入、审计发现和安全要求变化直接推动。
搜维长期参与 Microsoft 365、身份治理、特权权限治理、审计与记录与 Microsoft Purview相关工作，并在金融行业积累了持续服务经验。
结构示意 · SCHEMATIC
IDENTITY · MESSAGING · COMPLIANCE
FIG. 01
Exchange架构升级Active Directory安全混合身份建设Microsoft 365合规上线特权权限治理审计与记录Microsoft PurviewMicrosoft SentinelExchange架构升级Active Directory安全混合身份建设Microsoft 365合规上线特权权限治理审计与记录Microsoft Purview
SEC.02 Industry Observation — 行业观察
金融行业的IT项目，通常需要在平台演进、业务连续和审计要求之间建立边界
项目不仅要完成技术升级，还要控制切换风险、权限变化、记录留存及上线后的运营责任。
OBS. 01
核心平台升级首先是连续运行问题
Exchange与Active Directory承载通信、认证和大量应用依赖，版本升级不能只按软件安装理解，需要先掌握架构、容量、依赖和回退条件。
OBS. 02
目录安全整改不能脱离业务认证关系
管理员、服务账号、证书、组策略与旧应用长期交织。整改需要区分风险收敛、架构调整和应用改造，避免直接变更影响关键系统。
OBS. 03
Microsoft 365上线前需要先明确治理边界
云平台接入之前，应先确定身份来源、管理员权限、访问条件、数据范围、审计记录和保留责任，而不是上线后再补充规则。
OBS. 04
审计发现需要转化为可持续控制
整改并不止于关闭单个发现项，还需要明确技术控制、责任人、复核方式、例外处理和后续组织变化下的维护机制。
SEC.03Client Cases — 客户案例
从具体项目理解搜维在金融行业中的参与方式
03
金融机构的平台规模、监管边界和历史架构并不相同。以下案例围绕Exchange升级、Active Directory整改、Microsoft 365合规上线及审计整改展开。
EXCHANGE PLATFORM MODERNIZATION
大型Exchange邮件系统升级与架构迁移
某金融机构核心邮件平台
Exchange Server
架构升级
高可用
业务割接
01 · OVERVIEW
项目概览
项目类型
Exchange Server版本升级与邮件架构迁移
行业
金融业
企业特点
本地邮件平台长期运行，承载内部通信与应用邮件
涉及对象
员工邮箱、共享邮箱、数据库、邮件流、网关、客户端及应用中继
涉及平台
Exchange Server、Active Directory、DNS、负载均衡、邮件安全网关及备份平台
项目特点
在保持持续通信的前提下，并行建设目标环境、分批迁移邮箱并验证上下游系统
02 · BACKGROUND
项目背景
某金融机构长期使用本地Exchange作为核心通信平台。现有环境承载员工邮箱、共享邮箱、会议资源和多类应用邮件，随着服务器与软件版本进入升级窗口，原架构的容量、高可用和维护方式需要重新评估。
项目不能按原地升级简单处理。邮件系统与Active Directory、DNS、证书、负载均衡、邮件网关、归档及业务系统中继相互关联，需要先建立现状架构与邮件流视图，再设计目标环境、共存迁移、割接验证和回退条件。
03 · CHALLENGES
项目挑战
CHALLENGE 01
邮件平台属于关键基础设施
升级期间仍需维持内部和外部通信，停机窗口与故障影响范围受到严格限制。
CHALLENGE 02
历史架构与依赖关系复杂
数据库、副本、网关、证书、客户端及应用中继长期演进，部分关系缺少完整记录。
CHALLENGE 03
高可用不能只验证服务器状态
还需验证数据库切换、内部外部邮件流、客户端连接和依赖服务是否持续工作。
CHALLENGE 04
迁移与回退需要保持一致
邮箱、客户端、代理地址和邮件流在不同阶段变化，必须明确验证点与回退边界。
04 · OUR WORK
搜维主要参与内容
/ 01
现有Exchange组织与依赖盘点
梳理服务器、数据库、DAG、命名空间、证书、负载均衡、连接器、网关、归档和应用中继关系。
/ 02
目标版本与邮件架构设计
根据容量、高可用、运维和升级路径设计目标Exchange组织、数据库布局、网络入口和管理边界。
/ 03
并行环境与共存关系建设
部署目标环境，建立必要的版本共存、邮件路由、地址解析和客户端连接关系。
/ 04
迁移批次与验证清单制定
按邮箱类型、业务部门、数据量和应用依赖划分批次，明确邮件、日历、委派和客户端验证项目。
/ 05
生产割接与异常处理
在受控窗口完成关键切换，监控内部外部邮件流、数据库、网关和应用中继，并按预设条件处理异常。
/ 06
旧环境收敛与运营交接
确认邮箱和依赖迁移后逐步退出旧服务器，交接证书、备份、监控、补丁和故障升级责任。
05 · COMPARISON
项目前后对比
| 关注领域 | 项目前 | 项目后 |
|---|---|---|
| 身份管理原则 | 不同区域采用不同管理方式 | →建立统一身份管理原则 |
| 生命周期管理 | 入转调离处理方式存在差异 | →形成统一管理规范 |
| 权限管理 | 权限长期积累，依赖人工维护 | →建立权限管理机制 |
| 组织变更应对 | 不同团队处理方式不一致 | →明确责任分工和处理规则 |
| 外部身份管理 | 合作伙伴访问管理方式分散 | →建立统一管理要求 |
| 持续运营 | 更多依赖个别管理员经验 | →纳入长期运营和治理体系 |
06 · RELATED
项目关注领域
ACTIVE DIRECTORY SECURITY REMEDIATION
大型Active Directory环境梳理与安全整改
某金融机构目录与权限项目
Active Directory
特权账号
服务账号
安全整改
01 · OVERVIEW
项目概览
项目类型
Active Directory架构梳理与安全整改
行业
金融业
企业特点
目录环境运行多年，承载人员、终端和众多应用认证
涉及对象
域控制器、管理员、服务账号、组策略、证书服务及目录依赖应用
涉及平台
Active Directory、DNS、Group Policy、AD CS、Microsoft Defender for Identity及Microsoft Entra ID
项目特点
先识别目录与应用依赖，再分层收敛权限、升级基础组件并建立持续检查机制
02 · BACKGROUND
项目背景
某金融机构的Active Directory环境经过多年运行，覆盖总部与分支机构，并为终端登录、文件权限和多类业务应用提供认证。随着安全要求提高，历史管理员权限、服务账号、域控版本、组策略和证书使用方式需要系统梳理。
目录安全整改不能只按基线逐项修改。部分服务账号和权限组与业务系统存在直接依赖，域控制器升级又会影响DNS、复制和认证。项目需要区分可直接收敛的风险、需要迁移验证的架构问题，以及必须由应用团队配合处理的长期依赖。
03 · CHALLENGES
项目挑战
CHALLENGE 01
历史权限与真实用途难以对应
高权限组、委派权限和服务账号长期积累，部分使用关系缺少清晰所有者。
CHALLENGE 02
应用认证依赖不易被发现
LDAP、Kerberos、NTLM、证书和固定服务账号可能隐藏在旧应用和脚本中。
CHALLENGE 03
域控升级与安全调整相互影响
版本、复制、DNS和协议变化需要分阶段验证，不能在同一窗口集中修改。
CHALLENGE 04
整改后仍需持续维护
组织和应用变化会带来新的账号与权限，若没有复核责任，风险容易再次累积。
04 · OUR WORK
搜维主要参与内容
/ 01
林域、域控与安全关系梳理
盘点林域、站点、域控制器、DNS、信任、组织单位、组策略、AD CS和现有监控关系。
/ 02
管理员与服务账号用途核验
区分人员特权账号、服务账号、应急账号和委派权限，确认所有者、使用位置和替代条件。
/ 03
应用认证与旧协议依赖识别
结合日志和应用访谈识别LDAP、Kerberos、NTLM、证书及脚本依赖，形成整改影响清单。
/ 04
域控与基础组件分阶段调整
安排域控版本、复制、DNS、时间同步和必要安全配置的试点、验证与推广顺序。
/ 05
特权访问与异常行为监测建设
收敛高权限使用范围，建立分层管理、受控登录及目录异常行为的监测和响应依据。
/ 06
持续复核与变更责任交接
形成管理员、服务账号、组策略、证书和目录变更的复核方式及责任分工。
05 · COMPARISON
项目前后对比
| 关注领域 | 项目前 | 项目后 |
|---|---|---|
| 身份管理原则 | 不同区域采用不同管理方式 | →建立统一身份管理原则 |
| 生命周期管理 | 入转调离处理方式存在差异 | →形成统一管理规范 |
| 权限管理 | 权限长期积累，依赖人工维护 | →建立权限管理机制 |
| 组织变更应对 | 不同团队处理方式不一致 | →明确责任分工和处理规则 |
| 外部身份管理 | 合作伙伴访问管理方式分散 | →建立统一管理要求 |
| 持续运营 | 更多依赖个别管理员经验 | →纳入长期运营和治理体系 |
06 · RELATED
项目关注领域
M365 SECURITY & COMPLIANCE FOUNDATION
Microsoft 365上线前的混合身份与安全合规建设
某金融机构云平台上线项目
Microsoft 365
混合身份
条件访问
Purview
01 · OVERVIEW
项目概览
项目类型
Microsoft 365上线前的身份、安全与合规基线建设
行业
金融业
企业特点
计划引入云端通信与协作能力，需先明确接入和治理边界
涉及对象
员工、管理员、终端、邮件、协作数据及审计合规团队
涉及平台
Active Directory、Microsoft Entra ID、Microsoft 365、Microsoft Purview、Microsoft Defender及终端管理平台
项目特点
将云平台上线与身份、访问、数据、审计和运营责任同步设计，而不是先开放使用再补规则
02 · BACKGROUND
项目背景
某金融机构计划引入Microsoft 365的邮件、会议与文档协作能力。IT、信息安全和合规团队需要在正式上线前共同回答：账号由哪里产生、管理员如何授权、什么设备可以访问、哪些数据进入平台、外部共享如何控制，以及审计与保留由谁维护。
项目因此不以开通租户和迁移用户为起点，而是先建立本地Active Directory与Microsoft Entra ID的混合身份关系，明确管理员与普通用户访问条件，并选取代表性的邮件和协作数据验证信息保护、审计及长期运营方式。
03 · CHALLENGES
项目挑战
CHALLENGE 01
身份来源与云端账号需要稳定对应
本地目录属性、人员类型和云端对象若缺少明确关系，后续账号变更和权限管理将难以持续。
CHALLENGE 02
管理员与用户控制不能采用同一强度
高权限操作、普通办公和特殊业务场景需要不同认证、设备和访问要求。
CHALLENGE 03
数据范围与共享边界需要业务确认
并非所有内容都采用同一标签或阻断规则，需要结合资料性质和实际协作方式。
CHALLENGE 04
合规能力需要明确运营责任
审计、保留、警报和调查功能配置后仍需要有人复核、处理例外并适应组织变化。
04 · OUR WORK
搜维主要参与内容
/ 01
现有身份来源与用户类型梳理
梳理本地目录、人员类型、同步属性、管理员角色和特殊账号，确定进入云平台的身份范围。
/ 02
混合身份与管理员边界设计
设计目录同步、认证、管理员分层、多因素认证和高权限账号使用方式。
/ 03
用户、设备与访问条件建设
根据用户、设备状态、位置和风险设计访问条件，并通过小范围用户验证实际工作影响。
/ 04
数据、共享与信息保护基线
选取邮件和文档场景验证敏感度、外部共享、数据防泄漏及例外处理边界。
/ 05
审计、保留与安全事件接口建立
配置必要记录、保留和告警范围，明确与现有安全运营或SIEM平台的接口和处理责任。
/ 06
试点上线与运营交接
通过受控试点验证用户体验、支持问题和控制效果，交接账号、策略、审计和持续维护责任。
05 · COMPARISON
项目前后对比
| 关注领域 | 项目前 | 项目后 |
|---|---|---|
| 身份管理原则 | 不同区域采用不同管理方式 | →建立统一身份管理原则 |
| 生命周期管理 | 入转调离处理方式存在差异 | →形成统一管理规范 |
| 权限管理 | 权限长期积累，依赖人工维护 | →建立权限管理机制 |
| 组织变更应对 | 不同团队处理方式不一致 | →明确责任分工和处理规则 |
| 外部身份管理 | 合作伙伴访问管理方式分散 | →建立统一管理要求 |
| 持续运营 | 更多依赖个别管理员经验 | →纳入长期运营和治理体系 |
06 · RELATED
项目关注领域
AUDIT-DRIVEN GOVERNANCE REMEDIATION
审计要求推动的身份、权限与记录治理整改
某金融机构审计整改项目
审计整改
身份权限
操作记录
持续治理
01 · OVERVIEW
项目概览
项目类型
审计发现驱动的身份、权限与记录治理整改
行业
金融业
企业特点
内外部检查提出账号、特权访问、操作记录和保留方面的改进要求
涉及对象
人员账号、管理员、服务账号、关键平台日志及审计合规流程
涉及平台
Active Directory、Microsoft Entra ID、Microsoft 365 Audit、Microsoft Purview、Defender for Identity及Microsoft Sentinel
项目特点
将审计问题映射到系统对象、技术控制和责任流程，形成可验证且可持续的整改状态
02 · BACKGROUND
项目背景
某金融机构在内部审计或外部检查中发现，部分账号来源、管理员权限、离职回收、操作记录和数据保留方式需要进一步标准化。发现项横跨本地Active Directory、云端身份、Microsoft 365和安全日志平台，无法由单一系统配置独立关闭。
项目首先需要解释每个发现项对应的实际对象、风险和证据，再判断采用账号流程、权限收敛、技术策略、日志接入还是运营复核进行整改。对于无法一次调整的历史依赖，需要记录临时控制、责任人和后续处理条件。
03 · CHALLENGES
项目挑战
CHALLENGE 01
审计语言需要转化为技术对象
发现项通常描述管理风险，需要进一步映射到账号、权限、策略、日志和平台责任。
CHALLENGE 02
同一问题跨越多个系统与团队
人员来源、目录、云平台、安全运营和合规团队可能各自承担一部分控制。
CHALLENGE 03
历史依赖限制一次性整改
特殊账号、旧应用和既有权限无法立即取消，需要明确替代方案和临时控制。
CHALLENGE 04
整改完成需要可验证证据
不仅要调整配置，还需证明控制已生效、记录可查询且后续有人复核。
04 · OUR WORK
搜维主要参与内容
/ 01
审计发现与系统对象映射
逐项梳理发现内容、影响范围、涉及账号、平台、责任团队和所需验证证据。
/ 02
账号来源与生命周期控制整改
明确员工、外包、共享及服务账号的创建、变更、停用和复核责任，处理历史遗留对象。
/ 03
管理员权限与特权使用收敛
核验高权限角色和组成员，区分日常、运维和应急用途，建立申请、授权和复核依据。
/ 04
日志、审计与保留范围调整
确认关键操作和平台记录的来源、保存范围、查询入口及与现有SIEM或调查流程的关系。
/ 05
例外、补偿控制与整改验证
对无法立即关闭的依赖记录风险、临时控制和目标条件，并按审计要求准备验证材料。
/ 06
持续复核机制与责任交接
将整改后的账号、权限、日志和保留要求纳入周期复核及组织变更后的维护流程。
05 · COMPARISON
项目前后对比
| 关注领域 | 项目前 | 项目后 |
|---|---|---|
| 身份管理原则 | 不同区域采用不同管理方式 | →建立统一身份管理原则 |
| 生命周期管理 | 入转调离处理方式存在差异 | →形成统一管理规范 |
| 权限管理 | 权限长期积累，依赖人工维护 | →建立权限管理机制 |
| 组织变更应对 | 不同团队处理方式不一致 | →明确责任分工和处理规则 |
| 外部身份管理 | 合作伙伴访问管理方式分散 | →建立统一管理要求 |
| 持续运营 | 更多依赖个别管理员经验 | →纳入长期运营和治理体系 |
06 · RELATED
项目关注领域
SEC.04
FAQ — 常见问题
评估金融行业相关项目时，可以先判断现有环境与推进边界
04
以下问题用于说明常见项目判断，不替代针对目录、邮件、云平台、安全控制和审计要求的现状评估。
Q.01
Exchange版本升级是否可以按普通服务器升级处理？
通常不适合。邮件平台还涉及Active Directory、数据库、高可用、邮件流、网关、客户端和应用中继。项目需要先判断现有架构与依赖，再设计并行建设、邮箱迁移、切换验证和回退边界。
Q.02
Active Directory安全整改是否应先清理所有高权限账号？
应先确认账号用途、登录位置、服务依赖和替代方式。部分历史权限确实需要收敛，但若直接禁用服务账号或更改组关系，可能影响应用和计划任务。通常需要区分人员特权账号、服务账号和应急账号。
Q.03
金融机构引入Microsoft 365时，哪些事项应在上线前确认？
通常包括身份来源、管理员角色、多因素认证与条件访问、终端条件、数据进入范围、外部共享、审计记录、保留要求和运营责任。具体控制需要结合机构现有制度、业务范围和合规判断确定。
Q.04
审计整改是否等于完成一批安全配置？
配置只是整改的一部分。还应把审计发现映射到账号来源、权限申请、技术控制、记录保存、责任人、复核频率和例外处理。否则组织或人员变化后，同类问题可能再次出现。
Q.05
本地AD、Exchange和Microsoft 365能否长期共存？
可以形成混合架构，但需要清楚定义本地与云端各自承担的身份、邮箱、管理和安全职责，并持续维护同步、证书、连接器、邮件流及故障处理关系。是否长期保留，应由应用依赖和治理目标决定。
SEC.05
Next Step — 下一步
每个金融机构的系统依赖、监管要求与风险边界都不完全相同
案例能够提供参考，但Exchange升级、AD整改、Microsoft 365上线和审计治理仍需结合实际架构与管理要求判断。可以从当前变更或审计发现开始。
提交当前需求查看服务领域
01当前正在规划或处理什么事项
01当前正在规划或处理什么事项
02涉及哪些机构、系统或业务单元
03涉及哪些平台与现有系统环境
04目前最关注的问题或管理目标