行业经验 · HEALTHCARE & LIFE SCIENCES
医疗与生命科学企业从研发走向规模化时，
IT需要同时承接增长、协作与治理
从早期研发团队到多项目并行，IT开始面对更多外部合作方、更多应用连接，也要回答资料如何沉淀、权限如何随项目变化。
搜维更关注这些变化背后的基础关系：本地身份与Azure怎样衔接，微软云上的协作空间怎样承载研发项目，外部机构如何进入又如何退出，以及项目资料如何在审计需要时说得清楚。
结构示意 · SCHEMATIC
RESEARCH · CLOUD · GOVERNANCE
FIG. 01
Exchange架构升级Active Directory安全混合身份建设Microsoft 365合规上线特权权限治理审计与记录Microsoft PurviewMicrosoft SentinelExchange架构升级Active Directory安全混合身份建设Microsoft 365合规上线特权权限治理审计与记录Microsoft Purview
SEC.02 Industry Observation — 行业观察
医疗与生命科学行业的IT项目，通常需要在平台演进、业务连续和审计要求之间建立边界
项目既要支撑人员、应用和合作伙伴快速进入工作，也要逐步建立身份、云资源、研发资料和权限的长期管理基础。
OBS. 01
企业成长会重新定义IT基础
Exchange与Active Directory承载通信、认证和大量应用依赖，版本升级不能只按软件安装理解，需要先掌握架构、容量、依赖和回退条件。
OBS. 02
应用上云会重新连接本地与Azure
管理员、服务账号、证书、组策略与旧应用长期交织。整改需要区分风险收敛、架构调整和应用改造，避免直接变更影响关键系统。
OBS. 03
外部研发合作需要项目级边界
云平台接入之前，应先确定身份来源、管理员权限、访问条件、数据范围、审计记录和保留责任，而不是上线后再补充规则。
OBS. 04
审计准备需要落实到资料与权限
整改并不止于关闭单个发现项，还需要明确技术控制、责任人、复核方式、例外处理和后续组织变化下的维护机制。
SEC.03Client Cases — 客户案例
从具体项目理解搜维在医疗与生命科学行业中的参与方式
03
医疗与生命科学企业的研发阶段、外部合作和平台基础并不相同。以下案例围绕规模化IT升级、Azure混合架构、外部研发协作和审计准备展开。
SCALE-UP IT FOUNDATION
创新药企规模化发展中的IT架构升级
某创新药企业 · 成长期IT升级
成长期IT
混合身份
终端管理
协作基础
01 · OVERVIEW
项目概览
项目类型
企业规模化阶段的IT架构升级
行业
医疗与生命科学
企业特点
从创业期快速可用，走向研发、运营与组织规模化后的可持续管理
涉及对象
研发与职能员工、公司终端、人员账号、办公与研发协作空间、企业应用
涉及平台
Active Directory、Microsoft Entra ID、Microsoft 365、Intune、Microsoft Defender及Azure
项目特点
以企业成长阶段为主线，先统一身份、终端和协作基础，再为Azure与安全能力扩展留出接口
02 · BACKGROUND
项目背景
某创新药企业在创业早期主要使用基础邮箱、Office和少量业务应用。随着研发活动、内部团队和外部合作持续推进，账号创建、设备交付、资料共享和安全管理逐渐需要长期维护。
项目从身份、终端、Microsoft 365协作、基础安全和Azure资源关系入手，区分应统一的基础能力、可分阶段迁移的历史环境及仍由专业团队管理的系统。
03 · CHALLENGES
项目挑战
CHALLENGE 01
早期IT环境以快速使用为主
账号、设备和平台由不同人员快速开通，随着团队扩大，入职、调岗和离职处理开始需要统一来源与责任。
CHALLENGE 02
研发与办公工作边界交叉
办公文档、研发支持材料和外部合作内容可能进入同一协作平台，需要先区分空间和使用边界。
CHALLENGE 03
终端场景开始多样化
办公室、远程工作和部分实验支持场景并存，设备所有权与管理深度不能一概而论。
CHALLENGE 04
安全要求与业务节奏同时提高
业务希望继续快速推进，但安全和运维不能永远依赖人工补救，需要选择优先级而不是一次堆满策略。
04 · OUR WORK
搜维主要参与内容
/ 01
现有IT环境与用户类型梳理
先把人员类型、账号来源、设备、Microsoft 365空间和主要企业应用放在同一视图中，确定哪些基础关系必须优先统一。
/ 02
目录与云身份基础建设
明确Active Directory与Entra ID之间的身份来源、同步属性和管理员责任，使入转调离能够稳定反映到云端账号。
/ 03
Microsoft 365协作环境规范化
围绕Teams、SharePoint和OneDrive建立项目与部门空间的基本边界，减少重要资料长期停留在个人空间。
/ 04
终端纳管与安全基线建立
按公司设备、移动设备和远程场景设置不同纳管方式，并验证应用分发、设备状态与访问体验。
/ 05
安全与数据保护能力分阶段引入
从代表性邮件、文档和访问场景开始验证安全控制，先处理高价值问题，再决定是否扩大策略范围。
/ 06
运营责任与后续演进交接
将账号、终端、协作空间、策略和云资源的维护责任交给明确团队，为下一阶段应用上云和人员增长保留演进路径。
05 · COMPARISON
项目前后对比
| 关注领域 | 项目前 | 项目后 |
|---|---|---|
| 身份管理原则 | 不同区域采用不同管理方式 | →建立统一身份管理原则 |
| 生命周期管理 | 入转调离处理方式存在差异 | →形成统一管理规范 |
| 权限管理 | 权限长期积累，依赖人工维护 | →建立权限管理机制 |
| 组织变更应对 | 不同团队处理方式不一致 | →明确责任分工和处理规则 |
| 外部身份管理 | 合作伙伴访问管理方式分散 | →建立统一管理要求 |
| 持续运营 | 更多依赖个别管理员经验 | →纳入长期运营和治理体系 |
06 · RELATED
项目关注领域
AZURE HYBRID ARCHITECTURE
研发与业务应用逐步上云后的Azure混合架构建设
某生命科学企业 · Azure混合架构
Azure
本地环境
网络互联
云资源权限
01 · OVERVIEW
项目概览
项目类型
Azure与本地环境混合架构建设
行业
医疗与生命科学
企业特点
部分研发支持与业务应用进入Azure，本地目录与专业系统继续保留
涉及对象
Azure订阅与资源、本地服务器、AD/DNS、研发应用、云端管理员与运维团队
涉及平台
Azure、Active Directory、Microsoft Entra ID、VPN/ExpressRoute、DNS、Azure Monitor及Microsoft 365
项目特点
不以全量迁云为目标，重点建立本地与Azure之间可复用的网络、身份、权限和运营关系
02 · BACKGROUND
项目背景
某生命科学企业开始将部分新应用和研发支持系统部署到Azure，同时本地数据中心仍运行目录、文件和专业应用。两侧系统互访后，网络、身份、DNS、权限和监控形成新的跨环境关系。
项目不是全量迁云，而是明确云端与本地边界，并为网络、身份、名称解析、访问控制、日志及日常运维建立可持续关系。
03 · CHALLENGES
项目挑战
CHALLENGE 01
云端资源开始依赖本地身份与网络
Azure中的新应用仍需调用本地目录、DNS或内部服务，若按单个项目配置，依赖会在联调阶段集中暴露。
CHALLENGE 02
网络路径影响应用体验与故障边界
总部、本地机房、Azure区域和远程人员之间的访问路径不同，网络变化会直接影响应用可用性与排障范围。
CHALLENGE 03
云端管理员权限容易快速扩散
项目建设阶段容易为方便交付授予较高Azure权限，若缺少角色边界，临时权限会逐渐固化。
CHALLENGE 04
本地与云端采用不同运营方式
本地团队关注服务器与网络，云团队关注Azure资源，跨环境故障需要统一监控入口和升级关系。
04 · OUR WORK
搜维主要参与内容
/ 01
应用与资源边界梳理
逐项确认准备进入Azure的应用、依赖服务、访问人员和数据路径，区分真正云化部分与继续留在本地的组件。
/ 02
Azure基础架构与订阅结构设计
根据研发、测试和生产等环境划分Azure订阅与资源组织，并明确共享网络、日志和管理员权限的基础边界。
/ 03
本地与Azure网络及DNS连接
建立本地与Azure之间的VPN或专线相关连接、路由及DNS关系，使应用访问路径可以解释和排障。
/ 04
AD、Entra ID与云资源权限衔接
将人员账号、应用身份和Azure角色放在同一权限模型下，减少个人Owner或长期高权限账号承担系统运行。
/ 05
监控、日志和基础运维关系建立
把Azure资源健康、关键日志和网络状态接入可观察范围，明确本地与云端团队在故障定位中的接口。
/ 06
试点应用迁入与架构验证
选择有代表性的应用验证性能、身份、网络和运维流程，用实际结果校正后续应用上云的基础模式。
05 · COMPARISON
项目前后对比
| 关注领域 | 项目前 | 项目后 |
|---|---|---|
| 身份管理原则 | 不同区域采用不同管理方式 | →建立统一身份管理原则 |
| 生命周期管理 | 入转调离处理方式存在差异 | →形成统一管理规范 |
| 权限管理 | 权限长期积累，依赖人工维护 | →建立权限管理机制 |
| 组织变更应对 | 不同团队处理方式不一致 | →明确责任分工和处理规则 |
| 外部身份管理 | 合作伙伴访问管理方式分散 | →建立统一管理要求 |
| 持续运营 | 更多依赖个别管理员经验 | →纳入长期运营和治理体系 |
06 · RELATED
项目关注领域
EXTERNAL R&D COLLABORATION
外部研发合作项目的数字协作环境建设
某药企 · CRO/CDMO研发协作
CRO/CDMO
外部身份
项目空间
资料共享
01 · OVERVIEW
项目概览
项目类型
外部研发合作项目协作环境建设
行业
医疗与生命科学
企业特点
多个外部机构按项目阶段参与，合作人员和资料范围持续变化
涉及对象
内部研发团队、CRO/CDMO成员、研究机构、外部专家、项目工作稿与阶段性交付资料
涉及平台
Microsoft Teams、SharePoint Online、Microsoft Entra B2B、Microsoft 365及Microsoft Purview
项目特点
以合作关系而非组织架构划分访问范围，在较低接入门槛下控制项目资料、成员变化与退出
02 · BACKGROUND
项目背景
某药企与CRO、CDMO、研究机构和外部顾问共同开展研发项目。合作方需要参与会议、查看指定项目资料并提交阶段性文件，但其人员并不属于企业内部。
项目需要将外部参与者、项目空间和资料边界对应起来，同时保持合理接入门槛，并在项目或人员变化后及时调整访问。
03 · CHALLENGES
项目挑战
CHALLENGE 01
外部人员来自不同合作机构
合作参与者来自不同机构，账号来源、人员流动和项目周期不同，无法使用内部员工的生命周期方式直接管理。
CHALLENGE 02
资料范围受到项目关系限制
CRO、CDMO和研究机构承担的工作不同，只应访问各自项目需要的资料和空间，不能把项目协作等同于全员共享。
CHALLENGE 03
项目资料持续迭代和交付
工作稿、阶段材料和正式交付持续迭代，邮件附件和个人链接无法稳定表达当前版本和正式来源。
CHALLENGE 04
合作结束后访问需要退出
项目结束、人员替换或合作范围变化后，来宾账号、站点成员和历史共享需要同步复核。
04 · OUR WORK
搜维主要参与内容
/ 01
合作方、人员与项目关系梳理
按研发项目、合作机构和角色梳理实际参与者、合作周期、资料类型和现有传递方式，避免只按公司名称授权。
/ 02
外部身份与接入方式设计
为外部参与者设计Entra B2B邀请、访问条件和账号有效期，使人员变化可以在项目关系中被识别。
/ 03
项目协作空间与权限结构建设
使用Teams与SharePoint建立项目级协作空间，按机构和角色安排成员、文档库与访问范围。
/ 04
项目资料共享与保护方式验证
选择技术资料、工作稿和交付文件验证共享、下载和保护方式，确保安全控制不破坏正常研发合作。
/ 05
项目成员复核与阶段调整
在项目里程碑或合作人员变化时复核来宾、站点成员和共享链接，及时调整不再需要的访问。
/ 06
项目结束与外部身份退出
项目结束时同步处理资料归档、空间责任移交、外部身份回收和历史共享检查，而不是只关闭一个Teams团队。
05 · COMPARISON
项目前后对比
| 关注领域 | 项目前 | 项目后 |
|---|---|---|
| 身份管理原则 | 不同区域采用不同管理方式 | →建立统一身份管理原则 |
| 生命周期管理 | 入转调离处理方式存在差异 | →形成统一管理规范 |
| 权限管理 | 权限长期积累，依赖人工维护 | →建立权限管理机制 |
| 组织变更应对 | 不同团队处理方式不一致 | →明确责任分工和处理规则 |
| 外部身份管理 | 合作伙伴访问管理方式分散 | →建立统一管理要求 |
| 持续运营 | 更多依赖个别管理员经验 | →纳入长期运营和治理体系 |
06 · RELATED
项目关注领域
R&D ACCESS GOVERNANCE
审计准备推动的研发资料与身份权限治理
某生命科学企业 · 研发资料治理
审计准备
研发资料
访问权限
可追溯性
01 · OVERVIEW
项目概览
项目类型
研发资料与身份权限治理
行业
医疗与生命科学
企业特点
进入更规范的内部或外部审计准备阶段，需要解释资料、身份与访问关系
涉及对象
关键研发资料、项目站点、员工与离职人员、外部合作账号、共享关系与审计记录
涉及平台
Active Directory、Microsoft Entra ID、Microsoft 365、SharePoint Online、Microsoft Purview及Audit
项目特点
从代表性研发项目入手，把身份状态、项目权限、外部共享和审计记录串成可验证的治理关系
02 · BACKGROUND
项目背景
某生命科学企业进入更规范的审计准备阶段，需要回答关键研发资料位于哪些空间、哪些内部和外部人员可以访问、历史人员权限是否仍然存在，以及重要活动能否查询。
项目不把审计准备等同于一次扫描或批量加标签，而是选择代表性研发项目，将身份、项目空间、文件权限、外部共享和审计记录结合起来梳理。
03 · CHALLENGES
项目挑战
CHALLENGE 01
关键资料分布在不同协作空间
历史研发资料分散在团队站点、个人空间和归档位置，资料责任人与当前访问人员未必一致。
CHALLENGE 02
身份状态与项目权限不同步
员工转岗、离职或外部人员退出后，身份状态可能已经变化，但历史项目权限仍然保留。
CHALLENGE 03
共享行为存在合理业务例外
研发合作客观需要对外共享，治理重点是区分合理协作与超出项目关系的访问，而不是简单禁止外发。
CHALLENGE 04
审计证据需要能够解释关系
审计日志只有与身份、项目空间和共享对象对应起来，才能解释访问和权限变化发生在什么业务背景下。
04 · OUR WORK
搜维主要参与内容
/ 01
关键研发资料与项目空间盘点
选取代表性研发项目，定位关键资料、项目空间、资料所有者和现有访问人员，先形成可验证的事实范围。
/ 02
身份状态与权限关系核验
将员工、离职人员和外部合作方的身份状态与SharePoint、Teams等项目权限对应，识别失效或过度保留访问。
/ 03
项目空间与共享边界调整
依据当前合作关系重新划分工作空间、归档空间和对外共享边界，避免历史权限无限延续。
/ 04
数据分类与保护场景验证
针对真正需要控制的研发资料验证敏感度、下载和外发策略，并保留经业务确认的合作例外。
/ 05
审计记录与调查入口明确
确认关键共享、权限变更和访问活动在哪些日志中可查询，以及发生问题时由谁发起调查和提供证据。
/ 06
周期复核与项目退出机制交接
把成员复核、项目退出、外部身份和例外检查嵌入项目里程碑或周期任务，使治理不只发生在审计前。
05 · COMPARISON
项目前后对比
| 关注领域 | 项目前 | 项目后 |
|---|---|---|
| 身份管理原则 | 不同区域采用不同管理方式 | →建立统一身份管理原则 |
| 生命周期管理 | 入转调离处理方式存在差异 | →形成统一管理规范 |
| 权限管理 | 权限长期积累，依赖人工维护 | →建立权限管理机制 |
| 组织变更应对 | 不同团队处理方式不一致 | →明确责任分工和处理规则 |
| 外部身份管理 | 合作伙伴访问管理方式分散 | →建立统一管理要求 |
| 持续运营 | 更多依赖个别管理员经验 | →纳入长期运营和治理体系 |
06 · RELATED
项目关注领域
SEC.04
FAQ — 常见问题
评估医疗与生命科学行业相关项目时，可以先判断现有环境与推进边界
04
以下问题用于说明常见项目判断，不替代针对目录、邮件、云平台、安全控制和审计要求的现状评估。
Q.01
创新药企什么时候需要从基础办公升级到更完整的IT体系？
通常不是以员工数量单独判断。当研发项目、外部合作、终端和企业应用开始持续增加，账号来源、设备交付、项目资料和访问权限需要长期维护时，就值得重新检查整体IT架构。
Q.02
应用逐步进入Azure后，哪些本地能力通常还需要一起考虑？
要结合实际应用判断，但身份、网络、DNS、访问路径和管理员责任往往仍与本地环境有关。重点不是为了“混合云”而保留本地，而是把暂时不能拆开的依赖关系说清楚。
Q.03
CRO、CDMO等外部合作方，适合直接加入企业内部协作空间吗？
通常更适合按项目范围设计外部身份和协作空间。需要先明确合作方参与哪些项目、能访问哪些资料、允许什么共享方式，以及人员或合作关系变化后怎样收回访问。
Q.04
研发资料治理是不是给文件加标签就够了？
通常不够。文件标签只是可能采用的一类控制。更先要弄清资料在哪里、谁负责、谁能访问、哪些资料必须与外部合作方共享，以及项目结束后权限和资料怎样处理。
Q.05
审计准备阶段，IT团队最值得先整理什么？
可以先从具有代表性的研发项目入手，把人员身份、项目空间、外部共享、关键资料和可查询记录串起来。这样比先做一次全平台扫描，更容易判断哪些问题需要技术调整，哪些需要明确长期责任。
SEC.05
Next Step — 下一步
如果你正在推进研发平台、Azure或外部协作，不必先把问题整理成一张“标准需求表”
更有价值的起点，是把正在发生的研发或组织变化说清楚：新的应用准备上Azure，CRO/CDMO开始加入项目，旧的账号和共享关系需要整理，或者审计开始追问资料与访问依据。搜维可以据此判断先处理哪一层关系。
提交当前需求查看服务领域
01是哪一个研发阶段或业务变化触发了这次IT调整
01当前正在规划或处理什么事项
02哪些内部团队、CRO / CDMO或外部专家需要一起工作
03哪些应用、资料和身份仍在本地，哪些已经进入Azure或Microsoft 365
04这次更需要解决协作效率、访问边界，还是审计可解释性