[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],[],[[["\u003cp\u003eGoogle data centers prioritize data security through a multi-layered approach, utilizing both physical and logical controls across complex industrial environments.\u003c/p\u003e\n"],["\u003cp\u003eThe "physical-to-logical space," the area between physical machine access and its runtime environment, is secured using hardware hardening, anomalous event detection, and system self-defense.\u003c/p\u003e\n"],["\u003cp\u003eHardware hardening reduces the physical attack surface by minimizing access paths, such as ports, and implementing firmware-level lockdowns, with options for secure rack enclosures.\u003c/p\u003e\n"],["\u003cp\u003eAnomalous event detection uses real-time data streams and system software to quickly identify potential physical-to-logical security events, which is enhanced with hardware root-of-trust.\u003c/p\u003e\n"],["\u003cp\u003eSystem self-defense allows for immediate action against potential compromises by combining telemetry data to pinpoint high-risk events, triggering actions such as service termination, data wiping, and network isolation.\u003c/p\u003e\n"]]],[],null,["# How Google protects the physical-to-logical space in a data center\n\n*This content was last updated in May 2024, and represents the status quo\nas of the time it was written. Google's security policies and systems may change\ngoing forward, as we continually improve protection for our customers.*\n\nEach Google data center is a large and diverse environment of machines,\nnetworking devices, and control systems. Data centers are designed as industrial\ncomplexes that require a wide range of roles and skills to manage, maintain, and\noperate.\n\nIn these complex environments, the security of your data is our top priority.\nGoogle implements\n[six layers of physical controls (video)](https://www.youtube.com/watch?v=kd33UVZhnAA)\nand many\n[logical controls](/docs/security/infrastructure/design)\non the machines themselves. We also continuously model threat scenarios in which\ncertain controls fail or aren't applied.\n\nSome threat scenarios model insider risk and assume that an attacker already\nhas legitimate access to the data center floor. These scenarios reveal a space\nbetween physical and logical controls that also requires defense in depth. That\nspace, defined as *arms-length from a machine in a rack to the machine's runtime\nenvironment,* is known as the *physical-to-logical space*.\n\nThe physical-to-logical space is similar to the physical environment around\nyour mobile phone. Even though your phone is locked, you only give physical access\nto people who have a valid reason for access. Google takes the same approach to\nthe machines that hold your data.\n\nPhysical-to-logical controls summary\n------------------------------------\n\nWithin the physical-to-logical space, Google uses three controls that work\ntogether:\n\n- **Hardware hardening:** Reduce each machine's physical access paths, known as the *attack surface* , in the following ways:\n - Minimize physical access vectors, like ports.\n - Lock down remaining paths at the firmware level, including the basic input/output system (BIOS), any management controllers, and peripheral devices.\n- **Anomalous event detection:** Generate alerts when physical-to-logical controls detect anomalous events.\n- **System self-defense:** Recognize a change in the physical environment and respond to threats with defensive actions.\n\nTogether, these controls provide a defense-in-depth response to security events\nthat occur in the physical-to-logical space. The following diagram shows all\nthree controls that are active on a secure rack enclosure.\n\nHardware hardening\n------------------\n\nHardware hardening helps to reduce the physical attack surface to minimize residual risks.\n\n\u003cbr /\u003e\n\nA conventional enterprise data center has an open floor plan and rows of racks\nwith no barriers between the front panel and people on the data center floor.\nSuch a data center might have machines with many external ports---such as USB-A,\nMicro-USB, or RJ-45---that increase the risk of an attack. Anyone with physical\naccess to the data center floor can quickly and easily access removable storage\nor plug a USB stick with malware into an exposed front panel port. Google data\ncenters use *hardware hardening* as a foundational control to help mitigate\nthese risks.\n\nHardware hardening is a suite of preventative measures on the rack and its\nmachines that helps reduce the physical attack surface as much as possible.\nHardening on machines include the following:\n\n- Remove or disable exposed ports and lock down remaining ports at the firmware level.\n- Monitor storage media with high-fidelity tamper-detection signals.\n- [Encrypt data at rest](/docs/security/encryption/default-encryption#default_encryption_of_data_at_rest).\n- Where supported by the hardware, use device attestation to help prevent unauthorized devices from deploying in the runtime environment.\n\nIn certain scenarios, to help ensure that no personnel have physical access to\nmachines, Google also installs secure rack enclosures that help to prevent or\ndeter tampering. The secure rack enclosures provide an immediate physical\nbarrier to passersby and can also trigger alarms and notifications for security\npersonnel. Enclosures, combined with the machine remediations discussed earlier,\nprovide a powerful layer of protection for the physical-to-logical space.\n\nThe following images illustrate the progression from fully open racks to secure\nrack enclosures with full hardware hardening.\n\n- The following image shows a rack with no hardware hardening:\n\n- The following image shows a rack with some hardware hardening:\n\n- The following image shows the front and back of a rack with full hardware hardening:\n\nAnomalous event detection\n-------------------------\n\nAnomalous event detection lets security staff know when machines experience unexpected events.\n\n\u003cbr /\u003e\n\nIndustry-wide, organizations can take months or years to discover security\nbreaches, and often only after significant damage or loss has occurred. The\ncritical indicator of compromise (IoC) might be lost in a high volume of logging\nand telemetry data from millions of production machines. Google, however, uses\nmultiple data streams to help identify potential physical-to-logical\nsecurity events in real time. This control is called *anomalous event\ndetection*.\n\nModern machines monitor and record their physical state as well as events that\noccur in the physical-to-logical space. Machines receive this information\nthrough ever-present automated system software. This software may run on\nminiature computers inside the machine, called *baseboard management controllers\n(BMCs)*, or as part of an operating system daemon. This software reports\nimportant events such as login attempts, insertion of physical devices, and\nsensor alarms such as an enclosure tamper sensor.\n\nFor machines with hardware root-of-trust, anomalous event detection signals\nbecome even stronger. Hardware root-of-trust allows system software, such as BMC\nfirmware, to attest that it booted safely. Google detection systems, therefore,\nhave an even higher degree of confidence that reported events are valid. For\nmore information about independent roots of trust, see\n[Remote attestation of disaggregated machines](/docs/security/remote-attestation).\n\nSystem self-defense\n-------------------\n\nSystem self-defense lets systems respond to potential compromises with immediate defensive action.\n\n\u003cbr /\u003e\n\nSome threat scenarios assume that an attacker in the physical-to-logical space\ncan defeat the physical access measures discussed in\n[Hardware hardening](#hardware-hardening).\nSuch an attacker might be targeting user data or a sensitive process that is\nrunning on a machine.\n\nTo mitigate this risk, Google implements *system self-defense*: a control that\nprovides an immediate and decisive response to any potential compromise. This\ncontrol uses the telemetry from the physical environment to act in the logical\nenvironment.\n\nMost large-scale production environments have multiple physical machines in one\nrack. Each physical machine runs multiple workloads, like virtual machines (VMs)\nor Kubernetes containers. Each VM runs its own operating system using dedicated\nmemory and storage.\n\nTo determine which workloads are exposed to security events, Google aggregates\nthe telemetry data from the hardware-hardening controls and anomalous event\ndetection. We then correlate the data to generate a small set of events that are\nhigh-risk and require immediate action. For example, the combination of a secure\nrack door alarm and a machine chassis opening signal might constitute a\nhigh-risk event.\n\nWhen Google detects these events, systems can take immediate action:\n\n- Exposed workloads can immediately terminate sensitive services and wipe any sensitive data.\n- The networking fabric can isolate the affected rack.\n- The affected workloads can be rescheduled on other machines or even data centers, depending on the situation.\n\nBecause of the system self-defense control, even if an attacker succeeds in\ngetting physical access to a machine, the attacker can't extract any data and\ncan't move laterally in the environment.\n\nWhat's next\n-----------\n\n- For more information about physical controls, read about [data center security](https://www.google.com/about/datacenters/data-security/).\n- For more information about logical controls, read [Google infrastructure security design overview](/docs/security/infrastructure/design).\n- To learn about Google security culture, read [Building secure and reliable systems (O'Reilly book)](https://www.oreilly.com/library/view/building-secure-and/9781492083115/).\n\n\u003cbr /\u003e"]]
