Google 基礎架構安全性設計總覽

這篇文章的撰文時間是 2017 年 1 月,一切資訊均以當時的現狀為依據。由於我們不斷努力在提升客戶的安全保障,Google 的安全性政策及系統未來可能還會有所改變。

資訊長層級摘要

  • Google 具備全球規模的技術基礎架構,能夠保障資料在 Google 的整個資訊處理生命週期安全無虞。這套基礎架構可提供安全的服務部署功能、具備使用者隱私權保護機制的安全資料儲存服務、跨服務的安全通訊機制、與客戶在網際網路上的安全隱密通訊功能,以及管理者的安全作業程序。
  • Google 使用這套基礎架構來建立網際網路服務,包括 Google 搜尋、Gmail、相簿等一般使用者服務,以及 G Suite 和 Google Cloud Platform 等企業服務。
  • 我們的基礎架構採用漸進式分層安全機制,從資料中心的實體安全開始,到構成基礎架構根本的軟硬體安全,最後再採用技術性限制和程序支援作業安全性。
  • Google 為基礎架構的安全防護投注許多心血,集齊數百位工程師共同保護 Google 的安全性和隱私權,其中有許多都是公認的業界權威。

簡介

這份文件概略介紹了 Google 技術基礎架構中的安全性設計。我們的全球基礎架構專門用於保障 Google 的整體資訊處理週期安全性,可以提供安全的服務部署功能、具備使用者隱私權保護機制的安全資料儲存服務、跨服務的安全通訊機制、與客戶在網際網路上的安全隱密通訊功能,以及管理者的安全作業程序。

Google 使用這套基礎架構來建立網際網路服務,包括 Google 搜尋、Gmail、相簿等一般使用者服務,以及 G Suite 和 Google Cloud Platform 等企業服務。

我們也會介紹這套基礎架構採用的漸進式分層安全機制,首先是資料中心的實體安全,接著是構成基礎架構根本的軟硬體安全,最後則會說明用於支援作業安全性的技術性限制和程序。

Google 基礎架構安全性分層:多層式安全機制始於底層的硬體基礎架構,最頂層則是作業安全性。本文件會詳細介紹每個分層的特性。

安全的底層基礎架構

本節將說明我們如何保障基礎架構最底層的安全,包含實體設施、資料中心專用硬體,以及在所有電腦上執行的底層軟體堆疊。

實體設施的安全

Google 的資料中心由我們自行設計及建置,並採用了分層實體安全保護措施。能夠進入資料中心的只有極少數 Google 員工;為了保護資料中心樓層,我們運用了多種實體安全措施和多項科技,例如生物識別技術、金屬探測、監視攝影機、交通工具路障、雷射入侵偵測系統等。Google 有些伺服器是由第三方資料中心代管,針對這些伺服器,除了資料中心營運商提供的安全機制,我們也會額外加上由 Google 控管的實體安全措施;舉例來說,我們可能會在這些地點安裝獨立運作的生物識別系統、監視攝影機和金屬探測器。

硬體的設計和來源

一個 Google 資料中心有數千台連接至區域網路的伺服器,其中的伺服器主機板及網路設備都是由 Google 特別設計。我們會對合作的元件廠商進行審查,並謹慎選擇元件,也會和廠商共同稽核和驗證元件的安全性屬性。我們另外還設計了自訂晶片 (包含一種目前部署於伺服器和週邊設備的硬體安全性晶片),以便安全地識別和驗證合乎規定的 Google 硬體裝置。

安全的堆疊啟動和電腦身分識別

Google 伺服器使用了多項技術來確保能夠啟動正確的軟體堆疊。針對 BIOS、系統啟動載入程式、核心、底層作業系統映像檔等底層元件,我們使用了加密編譯簽名,每次啟動或更新時系統都會驗證這些簽名,且所有元件都由 Google 控制、建置及強化。隨著硬體不斷推陳出新,我們也持續努力提升安全性:舉例來說,我們會根據不同世代的伺服器設計,從可鎖定的韌體晶片、執行 Google 安全性程式碼的微控制器,或是上述由 Google 設計的安全性晶片中,取得啟動鏈的根信任。

資料中心中每部伺服器都有專屬的識別身分,可連結至硬體信任根 (RoT) 和用於啟動電腦的軟體。識別身分的用途是驗證來自和送往電腦上底層管理服務的API 呼叫。

Google 已撰寫自動化系統,以確保伺服器能夠執行最新版本的軟體堆疊 (包含安全性修補程式)、偵測及診斷軟硬體問題,以及在有需要時將電腦從服務中移除。

安全的服務部署作業

接下來要說明我們如何從底層軟硬體開始做起,確保服務能夠安全地部署在 Google 的基礎架構上。這裡的「服務」指的是開發人員為了在 Google 的基礎架構上執行而撰寫的應用程式二進位檔,例如 Gmail SMTP 伺服器、BigTable 儲存伺服器、YouTube 影片轉碼器,或是執行客戶應用程式的 App Engine 沙箱。為了因應工作負載的所需規模,可能會有數千台電腦一起執行同一服務的副本。在基礎架構上執行的服務由稱為 Borg 的叢集自動化調度管理服務負責控管。

就像本節稍後會提到的,我們的基礎架構不會假定在其上執行的服務之間彼此信任;換句話說,我們的基礎架構設計基本上就是為了支援多租戶技術。

服務身分、完整性及隔離功能

針對服務之間的通訊,我們會在應用程式層採用加密編譯驗證及授權,這種做法可在抽象層提供有效的權限控管方式,而且精細程度高,讓管理員和服務能夠自然掌握情況。

我們的主要安全機制並非仰賴內部網路區隔或防火牆,不過我們也的確在網路系統中的各個位置運用輸入及輸出過濾功能添加一層安全保護,以防範 IP 假冒行為,因為這種做法能夠盡可能提升網路的效能和可用性。

在基礎架構上執行的每項服務都有一個相關聯的服務帳戶身分,並且會獲得加密編譯憑證;對其他服務收發遠端程序呼叫 (RPC) 時,服務可以使用這些憑證證明自己的身分。用戶端會使用服務帳戶身分確保自己的通訊對象是正確的目標伺服器,而伺服器則會使用服務帳戶身分限制對特定用戶端的方法及資料存取權。

Google 的原始碼存放在中央存放區中,目前和過去的服務版本都可以在這裡進行稽核。基礎架構還能另行設定,要求根據受過審查、檢查及測試的原始碼建置服務的二進位檔。這類程式碼審查必須由作者以外的工程師 (至少一位) 進行檢測和核准,且任何系統程式碼的修改都必須由該系統的擁有者決定是否要核准;這些規定讓內部或外部的有心人士都無法輕易對原始碼進行惡意修改,同時也讓服務的來源有跡可循。

為了避免讓服務受到在同一電腦上執行的其他服務影響,我們採取多項隔離和沙箱技術,包含一般 Linux 使用者隔離、語言和核心式沙箱,以及硬體虛擬化。一般來說,我們會針對風險較高的工作負載採用較多層隔離措施;舉例來說,在使用者提供的資料上執行複雜的檔案格式轉換程式,或是在 Google App Engine 或 Google Compute Engine 上執行使用者提供的程式碼時,就會採取這種做法。為了再添一道安全防線,我們會在專屬電腦上另外執行高度機密服務,例如叢集自動化調度管理服務和部分金鑰管理服務。

服務間存取權管理

服務擁有者可以使用基礎架構提供的存取權管理功能,明確指定要允許哪些服務和自己的服務進行通訊。舉例來說,如果要讓某項服務只為列入特定許可清單的服務提供部分 API,擁有者可以為該服務進行設定,在許可清單中加入允許的服務帳戶身分,這樣基礎架構就會自動強制執行這項存取限制條件。

我們也會對存取服務的 Google 工程師核發個別識別身分,如此一來,擁有者也能夠透過類似的設定方式決定是否要讓工程師存取服務。這些類型的識別身分 (電腦、服務和員工) 都會放在基礎架構維護的全域名稱空間中,但使用者識別身分會另外處理 (本文件稍後會再行說明)。

這套基礎架構為內部識別身分提供了全面的身分管理工作流程,包含核准鏈、記錄和通知。舉例來說,這些識別身分可以透過允許雙邊進行控管的系統指派給存取權控管群組,如有一位工程師向群組提議進行變更,就必須由另一位工程師 (群組的管理員) 進行核准。採用這個系統,就能將安全存取權管理程序擴充到在基礎架構上執行的數千項服務。

除了自動化 API 層級存取權管理機制外,這套基礎架構還賦予服務從中央 ACL 和群組資料庫讀取資料的能力,進而在必要時採用精確的自訂存取權控管機制。

服務間通訊的加密

除了在前幾節提過的遠端程序呼叫 (RPC) 驗證和授權功能外,這套基礎架構也為網路上的 RPC 資料提供加密編譯隱私權及完整性。為了讓 HTTP 等應用程式層通訊協定也能享有安全性優勢,我們將這些通訊協定封裝在基礎架構 RPC 機制中,達成應用程式層隔離,這樣一來,就不需依賴網路路徑的安全性,即使網路遭到監聽或是網路裝置遭駭,已加密的服務間通訊還是可以安全無虞。

服務可以為每個基礎架構 RPC 分別設定所需的加密編譯保護等級,例如針對資料中心內的低價值資料,可以選擇只保護資料的完整性。為了防範企圖惡意監聽非公開 WAN 連結的駭客高手,基礎建設會自動加密資料中心之間通過 WAN 的所有基礎架構 RPC 流量,服務不需要就此進行明確設定。我們已經開始部署硬體加密編譯加速器,以便將這項預設加密作業應用至我們資料中心中所有基礎架構 RPC 流量。

使用者資料的存取權管理

一般的 Google 服務都是用來為使用者提供特定功能,舉例來說,使用者可能會將電子郵件儲存在 Gmail,而使用者和 Gmail 等應用程式的互動,會擴及基礎架構中其他服務,例如 Gmail 服務可能會呼叫由聯絡人服務提供的 API,以便存取使用者的通訊錄。

如上一節所述,我們可以設定讓聯絡人服務只接收來自 Gmail 服務 (或其他聯絡人服務希望允許的服務) 的 RPC 要求。

不過這種做法還是會涉及相當廣泛的權限,Gmail 服務可以利用這個範圍內的權限隨時向任何使用者的聯絡人提出要求。

由於 Gmail 服務是代表特定使用者向聯絡人服務提出 RPC 要求,基礎架構會給予 Gmail 服務在 RPC 中提出「使用者權限票證」的功能,這張票證可以證明 Gmail 服務目前確實是代表特定使用者提出要求,讓聯絡人服務能夠採用保護措施,只向票證中列出的使用者傳回資料。

這套基礎架構提供的中央使用者身分識別服務會核發「使用者權限票證」。中央使用者身分識別服務驗證了使用者的登入動作後會核發使用者憑證 (例如 Cookie 或 OAuth 憑證) 給使用者的用戶端裝置,之後用戶端裝置向 Google 發送的所有要求都必須提出該使用者憑證。

服務收到使用者憑證後,會將憑證轉交給中央使用者身分識別服務進行驗證,如果使用者憑證順利通過驗證,中央使用者身分識別服務就會傳回短期的「使用者權限票證」供和該要求相關的 RPC 使用。以剛才的例子來說,Gmail 服務會取得「使用者權限票證」,然後將票證轉交給聯絡人服務,之後呼叫的服務都可以在 RPC 呼叫中,就串接式呼叫向受到呼叫的服務提出「使用者權限票證」。

服務身分與存取權管理:基礎架構提供服務身分、自動化相互驗證、加密的服務間通訊,也能強制執行由服務擁有者定義的存取權政策。

安全的資料儲存作業

說明完如何安全部署服務後,接著要介紹我們如何在基礎架構上實行安全的資料儲存機制。

靜態資料加密

Google 的基礎架構提供多種儲存服務 (例如 Bigtable 和 Spanner) 以及內部金鑰管理服務,Google 大多數應用程式都是透過這些儲存服務間接存取實體儲存裝置。經過適當設定後,儲存服務可以在將資料寫入實體儲存裝置前,先使用中央金鑰管理服務的金鑰加密資料。這項金鑰管理服務支援自動金鑰輪換,可提供豐富全面的稽核紀錄,並且整合了之前提過的使用者權限票證,可為金鑰和特定使用者建立連結。

在應用程式層執行加密作業,可以將儲存空間較低層的潛在威脅 (例如惡意的磁碟韌體) 阻絕在基礎架構之外,不過這套基礎架構當然也採用了其他保護措施。我們會為硬碟和 SSD 提供硬體加密支援,並在硬碟的生命週期中謹慎進行追蹤。停用的加密儲存裝置在實際離開我們的監控範圍前,都必須經過多重步驟的清除作業 (包含兩項獨立驗證作業);沒有通過這項清除程序的裝置會就地銷毀 (例如透過機具碾碎)。

資料刪除作業

Google 的資料刪除作業大部分是先將特定資料標示為「預定要刪除」,而不是真的完全將資料移除,因此無論是客戶不小心刪除了資料,還是因內部發生錯誤或程序問題導致資料遭到刪除,我們都還是能夠將資料復原。資料標示為「預定要刪除」後,系統就會根據服務專屬的政策將資料刪除。

如果使用者將整個帳戶刪除,基礎架構會通知負責處理使用者資料的服務該帳戶已遭到刪除,接著,這些服務會為與遭刪除使用者帳戶相關的資料排定刪除的時程。透過這項功能,服務的開發人員就能夠輕鬆採行使用者控管機制。

安全的網際網路通訊

到目前為止,我們已經說明了 Google 如何確保基礎架構上的服務安全。在本節中,我們要介紹 Google 如何保障網際網路和這些服務之間的通訊安全。

如同之前提過的,我們的基礎架構是由許多實體電腦共同組成,所有電腦都透過 LAN 和 WAN 彼此相連,而服務間通訊的安全性和網路的安全性沒有關係。不過,我們確實將基礎架構隔離於網際網路之外,形成非公開的 IP 空間,因此在防禦阻斷服務 (DoS) 等攻擊時,我們只要將一小部分的電腦直接暴露於外部網路流量,就能輕鬆地增加一道保護防線。

Google Front End 服務

如果想要將服務公開在網路上,可以在一項稱為 Google Front End (GFE) 的基礎架構服務上註冊服務。GFE 可以確保在終止所有傳輸層安全標準 (TLS) 連線時,使用正確的憑證並遵循最佳做法 (例如支援完全正向密碼),另外還能針對阻斷服務攻擊提供防護 (之後會介紹更多細節)。接著,GFE 會為前述使用 RPC 安全性通訊協定的服務轉送要求。

事實上,所有要向外發佈的內部服務都會使用 GFE 作為智慧反向 Proxy 前端。這個前端提供公開 DNS 名稱的公開 IP 代管、阻斷服務 (DoS) 保護,及 TLS 終止功能。請注意,GFE 就像所有其他服務一樣,在我們的基礎架構上執行,因此可以依照收到的要求量進行擴充。

阻斷服務 (DoS) 保護

這套基礎架構規模龐大,所以 Google 能夠直接吸收許多 DoS 攻擊,不過我們另外還設置了多階層、多層次的 DoS 保護措施,讓在 GFE 後方執行的服務受到 DoS 攻擊的風險更低。

我們的中樞網路將外部連線傳送給其中一個資料中心後,會通過數層軟硬體負載平衡,這些負載平衡器會將連入流量的相關資訊回報給在基礎架構上執行的中央 DoS 服務;如果中央 DoS 服務偵測到 DoS 攻擊,就可以對負載平衡器進行配置,以減少或限制和該次攻擊相關的流量。

在下個分層中,GFE 執行個體也會將收到要求的相關資訊回報給中央 DoS 服務 (包含負載平衡器無法提供的應用程式層資訊),這樣一來,中央 DoS 服務便可對 GFE 執行個體進行配置,以減少或限制攻擊流量。

使用者驗證

DoS 保護的下一層防護機制是我們的中央身分識別服務,這項服務通常是以 Google 登入頁面的樣貌呈現在使用者眼前。除了要求輸入使用者名稱和密碼,這項服務會根據風險因素 (例如使用者是否使用相同的裝置登入,或者是在和以往相近的地點登入) 聰明地要求使用者提供額外資訊。驗證使用者的身分後,身分識別服務就會核發 Cookie 或 OAuth 憑證等可供後續呼叫使用的憑證。

使用者也可決定是否要在登入時使用第二項驗證因素,例如動態密碼或是防網路詐騙安全金鑰。為了讓 Google 以外的使用者也能享有安全優勢,我們在 FIDO 聯盟和多家裝置廠商共同合作,開發出通用第二因素 (U2F) 開放標準;相關裝置目前已經上市,而其他大型網路服務也已經開始跟隨我們的腳步,針對 U2F 提供支援。

作業安全性

到這裡我們已經介紹完 Google 基礎架構中的安全性設計以及一些安全作業機制,例如 RPC 的存取權控管。

接下來要說明我們實際上如何安全地進行基礎架構作業:我們在安全的情況下建立基礎架構軟體、善加保護員工的電腦及憑證,並設法抵禦內部和外部有心人士對基礎架構造成的威脅。

安全軟體開發

除了先前提過的中央來源控管及雙邊審查功能外,我們也提供程式庫,以避免開發人員置入特定種類的安全性錯誤。舉例來說,我們準備了相關程式庫和架構,可清除網路應用程式中的 XSS 漏洞,也建置了漏洞檢查工具、靜態分析工具、網路安全性掃描工具等自動化工具,以自動偵測安全性錯誤。

在最後一道關卡,我們會人工進行安全性審查,例如為風險較低的功能進行快速分類,或是為風險最高的功能進行深度設計和實作審查;這些審查由一群網路安全性、密碼編譯和作業系統安全性專家負責執行。審查後可能會產生新的安全性程式庫功能和漏洞檢查工具,可以應用於其他未來產品。

此外,我們也創立了安全漏洞獎勵計劃,只要在發現 Google 基礎架構或應用程式的錯誤後通知我們,就能獲得獎金;我們已經透過本計劃頒發了數百萬美元的獎勵金。

Google 也投注了大量心力,在我們使用的所有開放原始碼軟體中尋找零時差漏洞和其他安全性問題,並追蹤問題的來源;例如 OpenSSL Heartbleed 錯誤就是由 Google 找出來的,而我們為 Linux KVM 管理程序提交的 CVE 和安全性錯誤修正方法數量更是居於眾人之冠。

維護員工裝置和憑證的安全

我們投入了龐大的資源保護員工的裝置及憑證免於遭駭,同時也透過監控活動尋找潛在的駭客行動或非法的內部活動。為了確保我們的基礎架構能夠安全運作,這是非常重要的投資。

複雜精巧的網路詐騙經常以我們的員工為目標;為了防範這些威脅,我們捨棄了可能落入網路詐騙陷阱的動態密碼第二因素,要求員工帳戶都必須使用和 U2F 相容的安全金鑰。

我們花費了許多心力去監控員工用於進行基礎架構作業的用戶端裝置,確保這些用戶端裝置的作業系統映像檔皆已套用最新的安全性修補程式,也會控管可安裝的應用程式。我們還另外建置了一些系統,用於掃描使用者安裝的應用程式、下載項目、瀏覽器擴充功能和網路瀏覽內容,以確認公司用戶端的適用性。

我們授予存取權限的主要機制並非透過公司 LAN,而是使用應用程式層級的存取權控管,因此只有來自指定網路及地點,並且使用適當受管理裝置的特定使用者能夠存取內部應用程式 (詳情請參閱和「BeyondCorp」相關的延伸閱讀文件)。

降低內部風險

針對擁有基礎架構管理權限的員工,我們會主動限制和監控其活動,也會持續努力解決特定工作需要取得特殊存取權才能作業的情況,改而透過自動化功能,以受到管控的安全方式完成工作。舉例來說,我們會要求部分動作採取雙邊核准程序,以及透過受限 API 在不需公開機密資訊的條件下進行除錯。

Google 員工對使用者資訊的存取情況可透過底層基礎架構勾點進行記錄,Google 的安全性小組會主動監控存取模式,並調查異常事件。

入侵偵測

Google 擁有精密複雜的資料處理管道,可整合個別裝置上的主機信號、基礎架構上各個監控點的網路信號,以及來自基礎架構服務的信號。建置在這些管道之上的規則及機器智能會警告作業安全性工程師可能會發生的事件,我們的調查及事件回應小組則會全年無休地為這些潛在事件分類、進行調查,並採取適當應對措施。我們還會透過模擬攻擊演練衡量及改進偵測和應對機制的成效。

維護 Google Cloud Platform (GCP) 的安全

在本節中,我們會著重說明底層基礎架構的安全性如何為我們的公開雲端基礎架構 GCP 帶來優勢,也會以 Google Compute Engine 服務為例,詳細說明我們在基礎架構上專門針對這項服務建構的安全性提升措施。

客戶可以運用 Compute Engine 在 Google 的基礎架構上執行他們自己的虛擬機器。Compute Engine 在實作方面採用了多項邏輯元件,最主要是管理控制層和虛擬機器本身。

管理控制層會公開外部 API 介面,並自動調度管理虛擬機器的建立及遷移等工作。由於管理控制層是在基礎架構上以多種服務的形式執行,所以會自動取得基礎完整性功能,例如安全啟動鏈。個別服務會在獨立的內部服務帳戶下執行,因此每項服務只能取得向控制層其他部分進行遠端程序呼叫 (RPC) 時所需的權限。就像之前提過的,所有這些服務的程式碼都會存放在中央 Google 原始碼存放區,而程式碼和最終部署的二進位檔之間會有稽核追蹤紀錄。

Compute Engine 控制層是透過 GFE 公開 API,所以會使用基礎架構安全性功能,例如阻斷服務 (DoS) 保護和集中管理的 安全資料傳輸層 (SSL)/傳輸層安全標準 (TLS) 支援。選用的 Google Cloud Load Balancer 服務是以 GFE 為基礎建置,可以防護許多類型的 DoS 攻擊;客戶如果使用這項服務,他們在 Compute Engine VM 上執行的應用程式就可以獲得和 Compute Engine 控制層類似的保護。

使用者對 Compute Engine 控制層 API 的驗證作業是透過 Google 的中央身分識別服務執行,這項服務可提供駭客入侵偵測等安全性功能;授權作業則是透過中央 Cloud IAM 服務執行。

每當資料中心之間出現控制層的網路流量 (包含從 GFE 到其後方第一項服務,以及其他控制層服務之間的流量),基礎架構就會自動驗證流量並進行加密。此外,這套基礎架構也經過特別設定,能夠將資料中心內部分控制層流量加密。

每部虛擬機器 (VM) 都會和相關聯的虛擬機器管理員 (VMM) 服務執行個體一起執行。基礎架構會提供這些服務兩個識別身分,一個是供 VMM 服務執行個體用於進行自己的呼叫,另一個則是讓 VMM 代表客戶的 VM 進行呼叫;這種做法讓我們可以進一步區隔 VMM 呼叫的信任。

Compute Engine 永久磁碟會使用由中央基礎架構金鑰管理系統保護的金鑰進行靜態加密,以便允許金鑰自動輪換以及對金鑰存取情形執行中央稽核作業。

現在的客戶可以自行選擇要將自己 VM 的流量傳送到其他 VM,或是傳送到沒有危險的網際網路,甚至也能採用他們所選擇的流量加密機制。我們已經開始逐步為客戶 VM 間流量的 WAN 周遊躍點推出自動加密功能。就像之前提過的,基礎架構中所有控制層 WAN 流量都已經加密,未來我們計劃要利用前述的硬體加速網路加密功能,將資料中心裡的 VM 間 LAN 流量也加密。

使用開放原始碼 KVM 堆疊達成的硬碟虛擬化,是 VM 隔離性的基礎。我們將部分控制及硬體模擬堆疊移入核心外未經授權的程序,進一步強化了我們的 KVM 實作方式,也透過漏洞檢查、靜態分析和人工程式碼審查等技術對 KVM 的核心進行了全面性的測試。就如同之前提過的,近期公佈的 KVM 植入性安全漏洞,大多數都是由 Google 發現的。

最後一點,在確保資料存取情況遵循 Google 政策方面,我們的作業安全性控制項扮演了很重要的角色。Google Cloud Platform 旗下的產品 Compute Engine 在使用客戶資料時,會確實遵守 GCP 的客戶資料使用政策;換句話說,只有在為客戶提供服務時有必要的情況下,Google 才會存取或使用客戶資料。

結論

在本文件中,我們說明了 Google 基礎架構的設計如何協助我們達成安全建置、部署及運行網路規模服務 (包含 Gmail 等一般使用者服務和企業服務) 的目標,而我們的 Google Cloud 產品正是建置在這套基礎架構上。

為了確保基礎架構的安全,我們投入了龐大的心力,集齊數百位工程師共同保護 Google 的安全性和隱私權,其中許多都是公認的業界權威。

如本文所述,我們的基礎架構採用了多層式的安全性措施,不但十分講究實體元件、資料中心和硬體來源,致力於維護啟動、服務間通訊和靜態資料的安全性,更妥善保護服務的網路存取情形,並為了確保作業安全性而部署了技術及人事程序。

延伸閱讀

如要進一步瞭解特定領域的資訊,請參閱下列文件:

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
解決方案