除了代管式 Microsoft AD 提供的安全措施之外,您还可以选择在代管式 Microsoft AD 虚拟机上应用 Microsoft 安全基准。这些基准是业界标准的安全配置设置,托管式 Microsoft AD 可以将其应用于您的托管式 Microsoft AD 实例和网域控制器。
我们建议您先查看这些基准并在开发或预演环境中的受管 Microsoft AD 实例中对其进行测试,然后再选择在生产环境实例中应用。您可以与支持团队联系,详细了解这些基准或选择应用这些设置。
安全监控和保护
我们使用操作系统的内置杀毒软件来保护托管式 Microsoft AD 实例免受病毒和恶意软件的侵害。防病毒软件会扫描您的托管 Microsoft AD 虚拟机,并检测病毒、恶意软件和间谍软件等安全威胁。
然后,杀毒软件会记录这些安全事件,我们会根据需要对其进行分析和补救。
修补
Microsoft 会定期发布漏洞修复、安全更新和功能改进。这些补丁对于确保您的网域控制器保持最新状态并保持安全至关重要。
托管式 Microsoft AD 会先测试所有这些补丁,然后再将其应用于您的网域控制器。在测试期间,托管式 Microsoft AD 会验证客户用例、可用性、安全性和可靠性。补丁通过这些测试后,托管式 Microsoft AD 就会在您的网域控制器上应用该补丁。
修补期间的可用性
在应用补丁和更新期间,Active Directory 网域将保持可用。不过,您无法对这些网域执行任何更改操作,例如扩展架构、更新网域以及与 SQL Server 或 Cloud SQL 建立连接。
此外,在您发起的更改操作完成之前,托管式 Microsoft AD 不会对您已发起更改操作的网域应用补丁。
托管式 Microsoft AD 可确保每个区域内至少有两个网域控制器在运行,且这些网域控制器位于不同的可用性区域。托管式 Microsoft AD 一次只会更新一个网域控制器。对于每次网域控制器更新,代管式 Microsoft AD 都会添加并提升一个安装了最新经过验证的补丁的新网域控制器。新网域控制器达到正常状态后,托管式 Microsoft AD 会降级现有网域控制器。新网域控制器在托管式 Microsoft AD 将其提升为主网域控制器后开始使用。旧网域控制器在被降级后会停止处理请求。此流程可确保每个区域中随时至少有两个网域控制器在运行。
为确保您的应用能够访问主动网域控制器,应用可以使用 Windows DC 定位服务。这样,您的应用便可以在自动补丁流程中重新连接到新的网域控制器。
补丁发布时间表
我们的目标是在 Microsoft 发布 Windows Server 每月补丁后的 21 个工作日内,在所有托管式 Microsoft AD 网域控制器上测试并应用补丁。不过,我们会优先处理 Microsoft 针对网域控制器发布的严重安全漏洞补丁,并在 15 个工作日内予以应用。
凭据轮替和加密
托管式 Microsoft AD 使用多种方法来保护凭据。托管式 Microsoft AD 经常轮替凭据,并使用业界标准技术对其进行加密。为管理 AD 创建的凭据永远不会在实例之间共享。只有规模较小的支持团队和自动化系统可以访问这些凭据。托管式 Microsoft AD 在删除实例时会销毁这些凭据。
生产数据访问受限
托管式 Microsoft AD 采用多个系统和流程,以确保Google Cloud 工程师拥有托管式 Microsoft AD 网域的最低权限。只有少数值班工程师有权访问生产数据。他们只访问生产环境以在网域上进行恢复或执行高级问题排查。需要经过验证的理由才能继续进行这些访问,然后托管式 Microsoft AD 会在内部进行记录和审核。托管式 Microsoft AD 会自动执行大多数访问,因此它们无法访问 AD 数据。在极少数情况下,值班工程师可能需要这样做才能远程访问网域控制器。在这种情况下,远程访问使用 Identity-Aware Proxy (IAP),而不是公共互联网。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-11。"],[],[],null,["# About security hardening\n\nThis topic explains the various measures that we take to harden Managed Service for Microsoft Active Directory and minimize security\nvulnerabilities.\n\nNo public internet access\n-------------------------\n\nTo improve security, Managed Microsoft AD is not exposed to the public\ninternet. Managed Microsoft AD makes all connections through private IP from\nauthorized networks:\n\n- Hosting: Managed Microsoft AD hosts every VM that runs Active Directory in their own\n [VPC](/vpc/docs), which isolates users from each other.\n\n- Connecting: You can use authorized networks to connect to\n Managed Microsoft AD through private IP. Managed Microsoft AD handles the\n [VPC peering](/vpc/docs/vpc-peering) for these connections.\n\n- Patching: Managed Microsoft AD applies Windows patches to the Managed Microsoft AD VMs without\n using public internet access. For more information about how Managed Microsoft AD\n handles patching, see [Patching](/managed-microsoft-ad/docs/hardening#patching).\n\nShielded VM\n-----------\n\n[Shielded VMs](/security/shielded-cloud/shielded-vm) are virtual\nmachines (VMs) hardened by a set of security controls that help defend against\nrootkits and bootkits. Shielded VM's features protect all Managed Microsoft AD VMs at no additional cost.\n\nOS image\n--------\n\nManaged Microsoft AD VMs are seeded from the [public Compute Engine Windows\nServer 2019 image](/compute/docs/images). These images have\n[Shielded VM](/security/shielded-cloud/shielded-vm) features enabled and are\noptimized for running on Compute Engine infrastructure.\n\nMicrosoft security baselines\n----------------------------\n\nIn addition to the security measures provided by Managed Microsoft AD, you can also opt in for applying Microsoft security baselines on your Managed Microsoft AD VMs. These baselines are industry-standard security configuration settings that Managed Microsoft AD can apply on your Managed Microsoft AD instances and domain controllers.\n\nWe recommend that you review these baselines and test them on your development or staging Managed Microsoft AD instances before opting to apply on the production instances. You can [contact support](/managed-microsoft-ad/docs/get-support) to learn more about these baselines or to opt in for applying these settings.\n\nSecurity monitoring and protection\n----------------------------------\n\nWe use the operating system's built-in antivirus to protect the Managed Microsoft AD instances against virus and malwares.\nThe antivirus scans your Managed Microsoft AD VMs and detects security threats, such as viruses, malware, and spyware.\nThe antivirus then logs these security events which we analyze and remediate if required.\n\nPatching\n--------\n\nMicrosoft releases bug fixes, security updates, and feature improvements on a regular basis.\nThese patches are crucial to keep your domain controllers up to date and safe.\n\nManaged Microsoft AD tests all these patches before applying them on your domain controllers.\nDuring testing, Managed Microsoft AD validates customer use cases, availability, security, and reliability.\nAfter a patch passes these tests, Managed Microsoft AD applies it on your domain controllers.\n\n### Availability during patching\n\nWhile applying the patches and updates, the Active Directory domain remains available.\nHowever, you can't perform any mutate operations on these domains, such as extending the schema, updating the domain, and connecting with SQL Server or Cloud SQL.\nAlso, Managed Microsoft AD doesn't apply patches to domains for which you have already initiated mutate operations until the operation is complete.\n\nManaged Microsoft AD ensures that there are at least two domain controllers running per region for a domain in different availability zones.\nManaged Microsoft AD updates one domain controller at a time.\nFor each domain controller update, Managed Microsoft AD adds and promotes a new domain controller, with the latest validated patch.\nAfter the new domain controller reaches a healthy state, Managed Microsoft AD demotes the existing domain controller.\nThe new domain controller comes into use when Managed Microsoft AD promotes it.\nThe old domain controller stops serving requests after Managed Microsoft AD demotes it.\nThis process ensures that there are at least two domain controllers running in each region at any time.\n\nTo ensure that your applications can reach the active domain controller, the applications can use the Windows DC locator service.\nThis enables your applications to reconnect with the new domain controllers during the automated patching process.\n\n### Patching schedule\n\nWe have the objective of testing and applying patches on all\nManaged Microsoft AD domain controllers within 21 business days of when\nMicrosoft releases a monthly patch for Windows Server. However, we prioritize\nand apply critical security vulnerability patches that Microsoft releases for\ndomain controllers within 15 business days.\n\nCredential rotation and encryption\n----------------------------------\n\nManaged Microsoft AD uses several methods to protect credentials.\nManaged Microsoft AD frequently rotates credentials and encrypts them using\nindustry-standard techniques. Credentials created for managing AD are never\nshared between instances. Only a smaller-sized support team and automated systems can access these credentials. Managed Microsoft AD destroys these credentials when it deletes the\ninstance.\n\nRestricted production access\n----------------------------\n\nManaged Microsoft AD employs multiple systems and processes to ensure that\nGoogle Cloud engineers have minimal access to the Managed Microsoft AD\ndomain. Only a small number of on-call engineers have access to production data.\nThey access production environment only to perform a recovery on a domain or advanced\ntroubleshooting. These accesses require a validated justification before they\ncan proceed, and then Managed Microsoft AD logs and audits them internally. Managed Microsoft AD\nautomates most accesses such that they cannot access AD data. In rare scenarios, there might\nbe a need for on-call engineers to remotely access domain controllers. In these\ncases, the remote accesses use\n[Identity-Aware Proxy (IAP)](/iap/docs/concepts-overview), not the public\ninternet."]]