實體隔離對於現在的時空環境下，執行起來難以兼顧企業自動化的需求，然而，為了生產力而放棄這種機制，也使得這種需要高度保護的設施，像是工廠的生產環境、醫療院所的電子器材，以及政府單位的重要系統，曝露於IT環境的各式網路威脅。想要與資訊系統相互連接，進行必要的資料交換，又能維持這些設施的安全，透過單向閘道（Unidirectional Gateway，或是稱為Data Diode）傳輸資料，成為一種新興的防護機制。

隨著最近兩到三年，操作科技（OT）環境的資訊安全受到高度重視，這種單向網路傳輸的解決方案，近期有多款產品透過代理商陸續引進到了國內。例如，威雲科技代理的單向閘道系統DigiSAFE Data Diode，由新加坡科技工程有限公司（簡稱新科）開發軟體，並且委由智邦科技製造硬體。

DigiSAFE Data Diode網路系統的應用場景上，原先是針對政府機關和軍事單位裡，需要與外部網路隔離的環境溝通而設計，但隨著企業同時需要兼顧廠房的資安與數位轉型，單向網路系統也開始受到許多公司行號的關注。

從設備的架構上來看，DigiSAFE Data Diode大致可區分成2個部分，分別是傳送端（Sender）與接收端（Receiver），這兩個設備之間由特製的光纖傳輸線連接，使得網路流量只能從傳送端往接收端輸送，而無法從接收端回送到傳送端設備。

上述兩個單向網路傳輸設備，又各自與企業不同的網路連接，讓指定的裝置能藉由這種機制進行單向通訊，例如，資訊人員在企業IT環境中，使用WSUS派送修補軟體，到廠房環境裡的Windows嵌入式設備上，就可以透過這種機制傳輸，並且留下相關的記錄。

透過單向傳輸閘道進行網路通訊的優點在於，企業可藉此規畫指定的連線，讓原本需要利用其他中介裝置存放（例如隨身碟、光碟片等），再透過人工執行傳送的工作，變成能夠以電腦自動執行，省下手動操作的不便，同時也能夠避免各種人為操作可能會出現的錯誤，或者是負責人員不慎將機密資料攜出的風險。

新科推出的DigiSAFE Data Diode 3284單向網路閘道，總共有兩個設備，分別是上方的傳送器（Sender）與下方的接收器（Receiver），連接一般網路及受隔離的網路，提供單向傳輸機制。

透過專屬的光纖網路線形成單向網路傳輸系統

理論上，要讓網路流量單向傳輸，部署一般的防火牆設備來管制流量，我們就能藉由相關的政策，即可來達到目的。但要透過硬體元件來做到只能單向傳輸流量，具體來說又要如何做到呢？在DigiSAFE Data Diode上，是經由一條光纖網路線來連接傳輸端和接收端，利用光傳輸只會向前而不會返回的特性，來達成這樣的目的。

而這條專用的網路線，也和一般光纖的線材不同。為了能夠讓網路流量流入與輸出，通常光纖網路線是兩條一組，也就是一端會有2個接頭，而DigiSAFE Data Diode專用的光纖線路，則是僅有一條線，兩端各只有1個接頭。換言之，這條網路線是形成單向網路環境的關鍵，因為它，網路傳輸只能從其中一端設備傳送到另一端。

為了對應這樣的配置，我們可以看到在傳輸端和接收端設備上，所提供專屬的連接埠轉接器，僅有半邊是能夠連接前述的光纖網路線，另外一半則是被封起來，而無法連接一般的網路線， 以防管理員不小心拿成標準線材，來連接兩個單向網路系統裡的專屬設備。

至於在單向網路系統裡，其中一端負責傳送、另一端執行資料接收，以及送達隔離網路環境的作業，則由DigiSAFE Data Diode兩款設備來控制。單向網路傳送器僅負責將管理者指定的網路流量，收取後傳送到接收器，接收器再將收到的流量，送到隔離環境裡的特定端點電腦，或者是伺服器。在DigiSAFE Data Diode單向網路傳輸系統的兩個設備上，我們也可以從管理介面看到其不同之處。

大致上來說，傳輸端負責的是取得一般網路環境的資料來源，而接收端則是將收到的資料，再傳送到隔離網路環境裡的網路位置，因此，雖然在兩者的主控臺的儀表板中，都會顯示管理者開放了那些通訊協定，但在DigiSAFE Data Diode接收端的部分，多了兩項傳輸端所沒有的資訊，一是偵測傳輸器是否仍維持連線的心跳燈號，另一個是即時傳輸的速率，若是管理者需要檢查這套系統的運作是否正常，就要先從接收器的管理介面著手。

基本上，我們在兩款設備的主控臺上，就能看到所支援的通訊協定，這是針對傳輸器對於一般網路，以及接收器與隔離網路之間的傳輸能力，至於DigiSAFE Data Diode的傳輸器與接收器之間，則是藉由新科專屬的通訊協定來進行。

可得知對外網路開放的連接埠類型

在DigiSAFE Data Diode的管理介面上，主控臺儀表板優先呈現的內容，是目前設備裡的連線狀態，包含了本身連接埠的通訊情形、各種協定的啟用與否，以及自己的服務運作狀態等。

形成單向傳輸的光纖線路

有別於一般光纖網路線是兩條線一組，分別提供傳輸與回傳，連接DigiSAFE Data Diode 3284傳送器和接收器的網路線，則是只有一條，因此只能從一般網路傳送流量到受隔離網路，而無法反向傳輸。

傳輸器與接收器透過專屬單向網路線連接

新科DigiSAFE Data Diode 3284運作的方式，是藉由圖中黃色的單向光纖網路線，將傳輸端與接收端連接，使得網路流量只能從上方的傳送器，送往下方的接收器。

具備兩種型號，可選擇單一裝置，或傳送端和接收端為獨立設備款式

目前新科DigiSAFE Data Diode總共推出了兩種型號，分別是3283和3284，前者為1U機身，傳送端與接收端的連接埠在同一個面版；後者則採用兩個1U設備配置，傳送端及接收端互為獨立的兩個設備。

因為上述規畫的差異，也使得兩套系統的網路連接埠有所不同──3283分別對於傳送端與接收端，提供1個GbE的RJ-45埠、1個10GbE的SFP埠，以及1個管理用的RJ-45埠，不提供擴充網路介面的能力。

而3284的兩個設備上，則是各有1個GbE的SFP埠、8個RJ-45埠，以及1個管理用的RJ-45埠，若是企業需要更多的連接埠，3284也提供擴充介面，能連接更多網路環境裡的設備。

從其他的規格來看，兩種型號的傳送端或是接收端，都內建了8GB記憶體，以及500GB的資料暫存空間，吞吐量都是500Mbps。記憶體和儲存空間的部分，兩者都可擴充。差異在於，3283記憶體最大可升級到64GB，而3284則能增加到32GB。

對於企業和工業環境網路協定的支援，兩款DigiSAFE Data Diode不只能適用一般境常見的TCP、UDP、HTTP，以及HTTPS等協定，能夠傳送Syslog和SNMP追蹤流量，並且可以監控多種網路共用資料夾的存取協定，包含了SMB、SAMBA、CIFS、FTP，以及SFTP等。再者，新科針對工業控制環境的操作科技上常用的協定提供支援，因此，這個系列的設備也能傳輸OPC UA、OPC DA（又稱OPC Classic）、PI系統、Modbus，以及MQTT協定，還有視訊監視器傳輸影像時，會用到的即時串流協定RTSP等。

針對管理這系列單向閘道系統的機制，新科則是提供了內建的設備健康度監控功能，並且能夠透過發送Syslog、電子郵件、特定檔案，或者是SNMP追蹤流量等管道，發出警示通知。而在資訊安全的要求上，DigiSAFE Data Diode則是符合新加坡雲端安全聯盟（CSA Singapore）所制訂的安全評估共同準則（Common Criteria，CC）。

僅提供指定來源和目的地路徑的單向資料傳送，需事先進行設定

在DigiSAFE Data Diode的單向傳輸系統裡，並非接上網路線，任何流量都可以從來源的一般網路，傳送到受隔離的網路環境裡，管理者必須指定所需傳輸的來源和目的地，由這套系統偵測特定來源是否有需要傳送的資料，再將資料透過經由傳送器和接收器，送達到目的網路上的指定位置，讓在隔離環境的使用者，也能取用這些原本企業在一般網路環境提供的共用資料。

具體的設置方式來說，針對來源的部分，IT人員需要於傳送端設備的管理介面上，填入有關的設定。以SMB共享資料夾的資料鏡像複製（SMB Mapping）為例，就要提供一般網路上的網路資料夾路徑，以及存取的帳號和密碼等資料，這樣該系統才會監控這個共享資料夾的動態。

接著，我們也要在接收端設備的管理介面上，找到已經與傳輸端連結的來源資料夾，並且輸入隔離網路裡的共用資料夾設定，如此一來，這套單向傳輸系統從一般網路偵測到新資料時，便會傳送到前述的指定路徑，讓位於隔離網路環境的電腦也能存取相關內容。

為了驗證在單向傳輸網路支援的應用，我們到威雲科技看他們的測試。在該公司架設的環境裡有兩個網路，他們模擬了多種情境，包含傳送共享資料夾內容（透過SMB協定）、電子郵件、系統事件記錄（Syslog），以及SNMP網路流量追蹤等，將資料從外部網路的伺服器，透過DigiSAFE Data Diode 3284，傳送到受隔離的內部網路環境。

此單向傳輸的第一階段驗證而言，結果確實如預期，將所有資料轉送到指定的內部網路伺服器。這些資料包含了1,000個共享資料夾檔案、1,000封測試郵件（EML檔案）、1,010個Syslog事件記錄，以及1,000筆測試的SNMP流量追蹤封包。

接下來，我們也驗證DigiSAFE Data Diode 3284是否只能單向傳輸資料。

對於SMB協定的鏡像資料複製而言，我們在目的地伺服器上，新增了10個檔案，結果Data Diode沒有將這些資料複製到來源的檔案伺服器裡。

而在DigiSAFE Data Diode的運作原理上，該系統的接收端只從傳輸端接收資料，然後送到內部網路伺服器上，指定的資料夾路徑，因此這樣的結果符合預期。但反過來說，若是企業想要確保內外部的共享資料夾內容一致，可能就需要其他的機制來比對，才能防範上述情境發生。

針對電子郵件的傳輸上，我們也嘗試反向將信件回傳。因為DigiSAFE Data Diode的接收端不予處理，導致TCP連線無法建立，我們產生測試信件的應用程式便處於等候連線的狀態，沒有將信寄出。

類似電子郵件反向傳輸出現的連線異常情況，也發生在Syslog的測試過程。我們試圖在受隔離網路的檔案伺服器產生Syslog事件記錄，發送到外部網路的伺服器上，結果事件記錄產生器會顯示TCP錯誤10060的訊息，並指出原因是連線逾時。

至於SNMP追蹤封包的部分，我們也如同先前測試正向傳輸，用批次檔下達發送的指令，基於這裡使用UDP協定162埠，沒有特別檢查是否送達，也因此如同前述驗證共享資料夾同步的過程，完全不會出現任何的錯誤訊息，但因為DigiSAFE Data Diode的接收器沒有配置相關的執行規則，所以也同樣沒有將封包回傳到外部網路的伺服器上。

新科提出的單向網路閘道系統架構

在新科的單向傳輸網路結構上，主要會有傳送端（Sender）與接收端（Receiver）兩個節點設備，兩者之間透過單向光纖線路（綠色箭頭）連接，藉此達到只進不出的流量的效果。

傳送端與接收端則透過RJ-45網路線，與企業的一般網路及受隔離環境連接，而形成專屬的連絡通道。以圖中的示意圖為例，左側端點電腦透過DigiSAFE Data Diode，能傳輸資料到右端位於另一個網路上的電腦，但該臺電腦無法回傳資料到端點電腦的網路上。

可傳送Syslog到隔離網路環境，但無法回傳

為了驗證經由DigiSAFE Data Diode只能單向傳輸，我們嘗試從接收端的檔案伺服器反向傳送Syslog記錄，結果出現無法建立TCP連線的逾時錯誤訊息。

提供管制流量存取機制，資料傳輸有記錄可供查詢

值得留意的是，單向網路與一般的實體隔離措施之間，資料傳送有項最大的不同點，那就是前者會與兩個網路環境同時連接，而非只會接觸其中一端。因此，監控與管理存取的流量，在這套單向網路系統之中也是相當重要的功能。

以DigiSAFE Data Diode而言，原廠就在儀表板上，顯示設備所啟用的通訊協定。這裡的協定包含了一般IT環境裡常見的TCP、UDP，以及上網應用有關的HTTP和SMTP等，也涵蓋企業檔案共享資料夾會用到的SMB等。除了上述的協定之外，我們也看到這款設備支援了OT環境可能會出現的MQTT、Modbus，以及OPC UA等協定。

假如企業網路裡採用的通訊協定，是DigiSAFE Data Diode尚未支援的類型，代理商表示，原廠也提供客製化服務，增加對應的功能模組。

而在管理介面上，企業可管制上述於DigiSAFE Data Diode啟用的通訊協定，傳輸設備只接收從特定連接埠監聽的資料。換言之，企業能夠配置平常較少使用的連接埠，來避免遭到攻擊者濫用的機會。

如果企業想要加強安全性，也能指定須通過使用者身分驗證，才可以執行傳輸的工作。

若要持續監控上述的網路流量傳輸狀態，DigiSAFE Data Diode提供事件記錄可供查詢，或是能把這些記錄傳送到資安事件管理平臺（SIEM），以便進一步分析。

假如出現流量異常，或是這套系統的傳輸設備出現暫存空間不足等情形，該系統可以透過電子郵件等方式，通知管理者進行處理。

能限制僅收送特定連接埠的內容

管制傳輸流量的類型，以避免遭到攻擊者濫用而傳送無關工作流程的資料。以圖中的管理介面為例，這裡規範產線設備常見的MQTT協定，Data Diode只會從1883埠接收資料。

為了確保傳輸內容安全，原廠建議可搭配檔案消毒機制先行過濾

嚴格來說，新科這套單向網路傳輸系統的功能，主要還是偏重於流量傳輸的管理，對於流量是否暗藏了有害的內容，該系統沒有相關的偵測機制。因此，新科建議企業可以另外採用檔案消毒與重組系統（CDR），在傳送資料到單向閘道傳輸器前，檢查檔案裡是否出現有害的程式碼片段，經過CDR消除，重新組合成無害檔案。

不過，CDR執行檔案檢測的工作，是外部網路將資料送到DigiSAFE Data Diode之前。雖然原廠的單向網路部署示意圖裡，提到能夠與這類系統的搭配，但在DigiSAFE Data Diode的管理介面上，我們沒有看到相關設定介面。管理者若是想要得知傳輸資料的清理情況，仍然需要存取CDR的管理介面，才能得知那些資料可能存在有害內容。

可搭配CDR檢測傳送資料是否安全

在DigiSAFE Data Diode的應用情境裡，原廠建議要結合檔案消毒與重組系統（CDR）來運作，先進行處理後，再經由他們的單向網路設備傳送到隔離環境使用。

產品資訊

新科DigiSAFE Data Diode

●建議售價：廠商未提供

●代理商：威雲科技

●系統組成：傳送器、接收器

●機身大小：傳送器和接收器皆為1U

●吞吐量：500Mbps

●記憶體：8GB，最高可擴充至32GB

●可用硬碟空間：500GB，可升級或更換為固態硬碟

●網路介面：8個RJ-45埠，並提供擴充介面

 ●網路協定支援：HTTP、HTTPS、TCP、UDP、SNMP、OPC UA、Modbus、MQTT等

【註：規格與價格由廠商提供，因時有異動，正確資訊請洽廠商】

黑盒子AI，是深度學習的優勢也是包袱。正因為超越了人定規則的框架，才能從資料挖掘出更具預測力的推論模型，但也因此，無法讓人得知模型為何做出這樣的預測。這類無法解釋的AI，在深度學習爆紅之後，成為了學界和業界爭論不休的技術和信賴課題。

AI實用派有大量擁護者，例如Google，在2012年發現，深度學習可以大幅提高語音辨識的正確率後，就大力應用到各領域。同年的ImageNet影像辨識大賽中，CNN框架AlexNet也以85％的準確率大敗其他演算法而奪冠，更掀起深度學習在電腦視覺和影像處理上的風潮。CNN之父Yann LeCun還主張，不見得所有問題都需要AI解釋，因此力推不需仰賴人力標記的自監督式學習（Self-Supervised Learning，SSL），並認為，這是AI典範最有機會出現大變革的方向。

但，AI的解釋力，終究是業界無法閃躲的問題，尤其各國政府看見其爭議性後，已紛紛祭出法規來規範AI應用，歐盟GDPR的透明處理原則，更賦予用戶，對於個人化自動化決策（Automated Individual Decision-Making），擁有請求解釋、拒絕適用的權利，所以，像金融機構不靠人只用AI決定拒絕貸款時，就得給出拒絕的理由，或在醫療領域，也無法完全靠AI診斷，還需醫生綜合考量後做出決策，因為現有法律上認定，只有真人才能為診斷當責。

因此，也有一派專家積極尋找打開AI黑盒子的方法。例如IBM，應用LIME技術結合自行開發的對比解釋方法（Contrastive Explanations Method，CEM），來發展解釋機器學習模型的工具；而日本的富士通研究所，則是運用深度張量（Deep Tensor）以及知識圖譜（Knowledge Graph），試圖解釋深度學習模型，更結合傳統統計方法開發出廣泛學習（Wide Learning）技術，走出了可解釋AI的另一條路。

以深度張量與知識圖譜技術，提供DL模型解釋依據

富士通最著名的AI應用之一，是2017年與國際體操聯盟聯合開發的體操評分AI，結合雷射感測器，將選手的每個動作如四肢位置、關節曲直、旋轉角度等肉眼難辨的差異，即時建立成3D影像，再透過AI影像辨識來估算得分。這個全新的AI體操評分機制，目前已在2019年世界體操錦標賽中完成驗證，等奧會核准通過後，更可望成為2020年東京奧運的輔助裁判工具。這項技術的關鍵推手富士通研究所，就是富士通先進技術的第一線研發主力。

富士通研究所早在2017年，就揭露對可解釋AI的研究進展，結合了深度張量、知識圖譜兩種技術，來解釋以圖結構（Graph）類型資料所訓練的深度學習模型。

比如一項針對特定疾病與基因變異關聯性的研究，富士通研究所先用深度學習演算法，訓練出疾病與基因變異關聯預測模型，並將圖結構的訓練數據，改以張量（Tensor）這種數學表達形式來呈現。

接著，針對該模型的每個輸入數據及輸出結果進行反向驗證，以輸入數據中張量之間的相似性，來提取出影響AI決策的特徵，藉此來判斷哪些因素對AI推論結果有關鍵性的影響，再進一步以知識圖譜來呈現這些因素之間的關係，方便研究人員或醫生，來解釋特定疾病與變異基因的關聯。

不過，富士通研究所所長原裕貴表示，知識圖譜技術並非用來解釋AI的預測結果，而是呈現出各因素間的關聯，讓研究者自己找出有說服力的解釋。目前，日本醫學研究與開發機構（AMED）與京都大學合作的基因研究專案，已經開始採用這項技術。

另一個應用，則是金融業的融資信用評估模型，用來解釋信用評等與借貸者條件的關聯性。因為深度張量，能分析如匯款記錄之類的圖形結構數據，來確定影響信評AI決策的關鍵因素；而知識圖譜本身能收集廣泛的公司數據，包括有關母公司、子公司、股份持有人和董事會成員等，來呈現其關連性，並顯示出影響較大的因素，讓研究者能近一步解釋AI決策生成的原因。

以傳統統計方法建立多重假設，來解釋DL模型決策結果

2018年底，富士通研究所又揭露了可解釋AI研究的另一個新方向，稱為廣泛學習，專門用於個人化決策類型的深度學習模型。

一般深度學習，是尋找輸入數據與預測結果間的關聯，來建立起一個用來推論的模型，但廣泛學習，是先將數據屬性（欄位）進行排列組合，並從統計結果中找出更傾向標記結果（Labeling Categories）的重要假設，來建立起一個分類模型的方法。

原裕貴表示，快速從大量數據組合中提取出重要假設，同時快速消除不必要的假設，來建立一個分類模型，就是廣泛學習的技術概念。

而建立假設的過程，舉例來說，輸入數據有10項屬性，年齡、性別、有無駕照、是否結婚、興趣、職業、年齡、偏好的購物場所、網頁瀏覽紀錄、天氣等，每個屬性的變化可能是2種（是或否、男或女）、多種（年齡、興趣）到上百種（例如1％到99％），就需要將所有可能性進行排列組合，這也是建立假設的過程。

接著，廣泛學習會自動統計出每一種數據組合的結果，若統計結果中，100名擁有駕照的人，僅60人已經購買了該產品，購買率為6成，但10個已婚男子中，卻有9人都購買了該產品，購買率為9成，以此就能推斷，已婚男性相較於擁有駕照者更容易購買該產品，就能形成一條假設，富士通稱為這是一個知識區塊（Knowledge Chunk）。

廣泛學習模型，會建立大量知識區塊，並測試每一個區塊是否傾向標記結果，例如符合這些假設的人，是否會成為購買者（這就是標記結果）。接著，再透過知識區塊之間的關聯性，進一步調整其權重，讓模型做出比一般深度學習更精準的決策，比如富士通研究所在醫療數據的測試中，廣泛學習比深度學習的準確率提高了10～20％。

用AI來解決社會上的公平性問題，避免人為判斷偏差的爭議，是接下來的發展重點。─── 富士通研究所所長 原裕貴　（攝影／洪政偉）

富士通研究所先將廣泛學習在應用到行銷業務場景中測試，除了能用來分析客戶是否將購買了特定產品，也能反推出哪個類型的客戶最有可能是該商品的購買者，比如在上述案例中的已婚男性可能有很高的購買率，就能主動向這類客群進行分眾行銷。富士通研究所指出，廣泛學習的優勢，不僅在於更精準的決策結果，更重要的是，這種模型決策過程，容易讓人解釋，哪些假設對預測結果具有更強的影響力，而且，在訓練資料不足情況下，就算只有幾十筆資料，廣泛學習仍然可以建立可供判斷用的假設，這也意味著，若日後積累了更多數據，還能執行更準確的測試。

未來，富士通研究所則希望能將廣泛學習應用到更多場景，例如製造業瑕疵檢測，試圖找出造成瑕疵的原因，並解決訓練資料不足的問題，或用於醫療診斷時的輔助，比如讓AI根據患者的治療用藥進行藥物分析，找出「40多歲吸菸男性患者服用A藥物可以大幅改善症狀」的證據，讓醫生更容易對患者解釋和說明開藥依據。

此外，原裕貴表示：「AI運算中，仍有一段最佳化、最佳解題的計算，可藉助DAU來處理，跟以前單純用AI演算法去處理相比，AI演算法加上最佳化解題的運算方式，可以算得更快。」這個DAU，就是富士通研究所研發的另一項技術，量子退火晶片（Digital Annealing Unit，DAU），可以平行計算上千個變數的多項式方程式，來找出最佳解，可用來處理特定AI問題的最佳解計算。

這項技術已經初步產品化，已先用於日本郵政的物流配送調度上，因為日本郵局調度貨車派送要考慮的因素很多，包括了車輛類型、郵差工時、運送成本、包裹種類、運輸距離、載重和容量限制、包裹重量、運送時間，甚至還要考慮道路情況等63項條件，光是5臺車派送包裹給6名顧客，就可能會有 10億種組合，想要找出最佳的物流調度方式，靠傳統的計算方法非常困難。

2018年時，日本郵政在埼玉市的新岩槻郵局進行了這項DAU實驗計畫，利用數位退火服務來尋找最佳物流路線和運輸方式，當時經過4～5個月的測試後發現，原有52輛貨車可以減少到48輛就夠了，貨物裝載率也提升12%，而且，只需要1秒，就可以依據輸入條件，找出一個物流方式最佳解。

不過，DAU也有其缺點，難以靠其他技術或演算法來驗證結果，得靠實證來檢驗。原裕貴坦言，數位退火技術不是尋求數學上的最佳解，而是找出一個比現在作法更好的答案，「富士通實測時，還沒有因此而帶來更高成本，但也有機會持續改進。」

透過自動化調校模型表現的技術，解決AI預測力下降問題

一邊打開AI的黑盒子，富士通研究所也要解決其他造成AI不被信賴的問題。其中，隨著時間、環境變化及新輸入資料的影響，AI模型預測準確率會逐漸下降，原裕貴稱之為「劣化」。

以金融信用風險評估模型為例，會受到經濟狀況變化、匯率、價格、利率的波動以及海外趨勢、法規的影響，在首次訓練完並部署後，準確度會逐漸變差，一般作法上，得定期增加新數據，重新訓練模型來改善。

可是，AI模型的維運人員無法時時監測模型表現，即使模型劣化嚴重也不一定能即時得知，若未即時改善，模型劣化後做出的錯誤決策，更可能降低企業內外部服務的效率，甚至造成業務過失，再加上，模型重新訓練的過程，又得再次耗費人力標注與訓練的成本。

為此，富士通研究所也在2019年10月時，發表了一個全球首創的AI模型「自動」修正預測力的技術，稱為「高耐久性學習技術（High Durability Learning）」。簡單來說，這項技術是將AI模型訓練用數據，繪製成分布圖，同時也將分佈圖轉換為拓撲空間（Durable Topology Space）的表現形式，接著，將模型使用過程中的輸入數據，持續繪製成兩種圖表，來看監看數據分布的趨勢變化。

藉由兩種數據分布圖的變化，AI模型就能自動偵測輸入資料跟模型表現之間的關係，並調整決策的參考依據，來維持模型準確率，延緩模型劣化速度及重新訓練的頻率。富士通研究所實際以3,800家企業的財務數據及信用風險評模型來測試，剛訓練完成的AI模型準確率為91%，隨著環境變化，當模型劣化到僅剩69%時，有應用高耐久性學習的模型還能維持在89%。

AI模型的品質，還有一個更根本的議題，就是AI倫理，原裕貴表示，這也是全世界都很關注的議題，富士通很早就開始關注，也在去年3月公開一份全集團都得遵守的AI承諾書，要來發展以人為本的AI技術。「用AI來解決社會上的公平性問題，避免人為判斷偏差的爭議，或是，建立公平處理的AI，來防止AI造成更多的不公平，就是接下來的發展重點。」他說。

CTO小檔案

原裕貴

富士通研究所所長

學歷：日本東京大學工學博士

經歷：1984年加入富士通研究所，並在1991年成為MIT營運研究中心客座研究員，2009年擔任軟體與解決方案研究部長、2013擔任社會創新研究部長，2015年則轉任知識情報處理研究部長，且兼任大數據戰略負責人，2017年起任職富士通AI事業部專員，直到2019年上任富士通研究所所長。

公司檔案

富士通

● 地址：東京都港區東新橋1-5-2汐留市中心

● 成立時間：1935年

● 網址：www.fujitsu.com/jp/

● 員工數：132,138人（2019年3月31日）

● 年營收：3兆9524億日圓

● 執行長：時田隆仁

● 科技部門：富士通研究所

● 科技部門主管：原裕貴

● 科技部門人數：約900名

公司大事紀

● 2015年：推出數位商務平臺MetaArc以及人工智慧系統平臺Zinrai

● 2016年：開發了類量子電腦的量子退火運算技術

● 2017年：與國際體操聯盟合作建立體操比賽的AI裁判系統

● 2018年：總部決定從IT企業轉型為DX（Digital Transformation）企業。開始開發可解釋AI技術Wide Learning

● 2019年：發表開發高耐久性學習技術（High Durability Learning）

在2019年底，我們發布了《雲端儲存的多元化面貌》的封面故事，依照IaaS和SaaS等兩種服務提供模式，介紹公有雲業者提供的3大基礎儲存空間服務（物件儲存服務、區塊儲存服務、檔案儲存服務）、5種進階儲存空間服務（高I/O效能應用、長期歸檔儲存、一寫多讀WORM儲存、加密儲存、混合雲儲存），以及4種基於軟體的應用服務（災難備援服務、備份服務、資料庫服務、第三方儲存軟體平臺）。對於後兩者，我們當時已整理出主要業者與解決方案，可惜限於篇幅，並未談及基礎儲存空間服務的狀況。

今年，我們想繼續針對這個部分，具體剖析個別的服務類型。談到雲端儲存服務，很多人會想到的是物件儲存服務（例如AWS的S3），然而，考量到當前企業全面上雲日益顯著，於是，我們決定先介紹與支援關鍵應用系統工作負載密切相關的區塊儲存服務。

關於區塊儲存的存取，根據《Cloud and Virtual Data Storage Networking》一書所言，是指最低階的存取方式，也是用於所有儲存系統的基礎建構模塊，不論應用程式是透過API、物件、檔案，或是經由檔案系統、資料庫、電子郵件或其他管道所提出的區塊存取請求，都是以最低階的方式來進行處理。而這裡所謂的最低階，是指從傳統硬碟、固態硬碟或磁帶等儲存環境，執行資料的讀取與寫入時，都是以一個個的資料區塊來處理，在作業上，可說是最「原汁原味」。

相較於物件儲存，區塊儲存較適合大型資料庫系統、郵件伺服器、伺服器虛擬化（虛擬機器）、RAID等使用場景，這些都是對儲存I/O效能較為敏感的應用，它們過去也被認為較不適合移植到伺服器虛擬化環境當中──因為共用儲存與網路的I/O負擔會很重（在伺服器虛擬化環境，也可執行另一套伺服器虛擬化系統，稱為巢狀虛擬化，但效能會折損得很嚴重），因此，許多企業目前並未將這類系統進行虛擬化，或是設法導入全快閃儲存組態，來支撐此類工作負載。

而對於公有雲環境的區塊儲存服務而言，由於幾家主要業者幾乎都提供基於固態硬碟與傳統硬碟的服務項目選擇，因此，在單一公有雲的環境當中，能夠因應多種效能與容量的要求。

根據6大雲端服務業者公開的規格資訊來看，若採用固態硬碟型的區塊儲存服務，還可選擇效能性或通用型SSD，以前者而言，每個磁碟可提供的效能，高達數萬到十多萬IOPS（以Azure Ultra Disk為例，可提供16萬IOPS與2000MB/s的吞吐量，儲存容量最大可選購64TB）。

除了考量效能等級是否合乎企業應用的需求，原本在企業級儲存陣列設備或軟體定義儲存系統當中，所具備的資料加密、可用性與耐久性、快照資料保護等進階功能特色，在公有雲區塊儲存是否有對應的服務提供，也是我們本次整理的重點。

關於公有雲服務提供的這些機制，在大型儲存廠商的產品當中，應該都是具備的，甚至還有更多，不過，若是中小型儲存廠商的產品，可能就未必都有，例如，快照資料保護的功能是有的，但不一定提供資料加密，至於資料儲存的可用性與耐久性，很少看到廠商提出具體的服務等級保證。

若用戶對於公有雲業者提供的區塊儲存服務，在功能上，有更多期待，目前幾家大型儲存廠商，像是NetApp、Pure Storage、HPE、Dell EMC，也和AWS、Azure、GCP展開合作，推出了雲端儲存陣列，過去兩年以來，我們持續追蹤報導這些廠商與解決方案的動態，而隨著公有雲業者不斷提升自身儲存服務的容量、效能與功能，雖然與企業級儲存廠商會形成更顯著的競爭關係，但由於他們與公有雲業者合作推出雲端儲存陣列，在解決方案的提供上，仍有因此受惠的可能性。相形之下，中小型儲存廠商的產品，面對雲端服務業者的進逼，以及他們與企業級儲存廠商的合作，後續若要拓展企業市場的規模，勢必將會面臨更大的挑戰。

 相關報導  透視公有雲區塊儲存服務

一般公有雲的區塊儲存（Block-Level Storage）服務，對應的是傳統的區塊儲存裝置，目的是為公有雲的執行個體、虛擬機器等運算單元，提供本機磁碟區形式的儲存空間。

公有雲區塊儲存服務問世至今，不過10年出頭時間，例如其中最具代表性的AWS EBS，是在2008年8月才上線服務，仍是相對新興的領域，但是在軟體定義儲存與儲存媒體技術的驅動下，已發展出豐富的產品形式與功能。

公有雲區塊儲存的2種基本型態

如同本地端的區塊儲存應用架構，可以區分為本機直連儲存裝置，以及SAN網路儲存等兩種基本型態，公有雲的區塊儲存也能分為兩種基本型態：一為運算單元本機直接附屬儲存空間，另一為透過遠端連結的網路化儲存空間。

運算單元附屬的區塊儲存

最初的公有雲區塊儲存，是運算單元的附屬儲存空間，例如AWS EC2的執行個體，都內含了一定容量的執行個體儲存空間（Instance stores），這種區塊儲存空間能提供相當可觀的容量與效能，如EC2的執行個體儲存空間容量可達32GB～60TB，若需要高I/O效能，也有NVMe SSD形式的儲存媒體可選，但由於這種儲存空間是運算單元的附屬，並不會將資料寫入底層的根裝置中，所以當運算單元停止運作時，執行個體儲存空間內的資料也會隨之消失，無法長久持續保存資料。

所以，這類區塊儲存適合網頁伺服器負載平衡之類的用途，對這類應用來說，當執行個體的工作結束後，資料也跟著消除，不需長久保存，可提供較佳的經濟性。

網路化的公有雲區塊儲存

這是一種獨立於執行個體外的公有雲區塊儲存服務，透過遠端掛載機制（通常是使用iSCSI協定），將儲存空間提供給指定的執行個體使用，對應於本地端的SAN儲存設備。

這類區塊儲存服務是獨立於運算單元外，即使掛載的執行個體停止運作，資料仍繼續保存在區塊儲存裝置上，可以長期保存資料，但使用成本也較高——獨立的公有雲區塊服務，也是獨立於運算服務外計費，用戶必須承擔儲存與運算兩種服務的成本，即使運算單元的工作結束，也還是必須繼續支付儲存服務的成本。

儘管成本較高，但這類獨立的公有雲區塊儲存適用範圍，仍比運算單元附屬區塊儲存服務來得更廣，不僅能長期保存資料，同時，還能提供多種強化資料存取可用性與安全性的資料服務功能，因而也成為當前公有雲區塊儲存應用的主流與發展重心。幾乎每家公有雲服務商都能提供這類區塊儲存，如AWS EBS、Azure Premium Blobs、Google Cloud的Persistent Disk、IBM Cloud的 Block Storage、Oracle Cloud的Block Volume Services，以及阿里雲（Alibaba Cloud ）的Block Storage等。

SSD帶來公有雲區塊儲存新發展：提供更多樣化的服務層級

大約在5、6年前，公有雲區塊儲存領域迎來一波重大變化，透過引進快閃儲存架構，大幅提高了公有雲區塊儲存服務的效能，不僅藉此擴展了應用範圍，也形成了更豐富了服務層級與類型。

以AWS來說，最早是在2012年8月，為DynamoDB資料庫服務與部分高階EC2運算服務，在EBS上提供了基於SSD的佈建IOPS（Provisioned IOPS）儲存服務類型，開始將公有雲區塊儲存帶向固態儲存領域，讓公有雲儲存首次擁有保證I/O效能的服務能力。隨後AWS又於2014年擴大了快閃儲存應用範圍，推出成本較低的一般用途SSD（General Purpose）服務。

類似的，Google Cloud也是在2014年中，開始提供SSD形式的Persistent Disk區塊儲存服務。

到了今日，SSD已成為公有雲區塊儲存服務的核心，一些雲端服務商的區塊儲存服務甚至已走向全面SSD化（如Oracle Cloud的Block Volume Service），搭配效能調節技術來向用戶提供不同等級的效能。

不過，多數的公有雲區塊儲存服務，仍然保留硬碟來提供低成本儲存服務，藉此提供2種主要的服務層級——SSD型與硬碟型。

SSD型區塊儲存服務

採用SSD為儲存媒體，以提供重視效能的應用環境為目的，通常又能分為效能型與標準型等2類。

● 效能型SSD

以支援資料庫等I/O密集型、重視效能的應用環境為目的，例如AWS EBS的佈建IOPS（Provisioned IOPS）儲存服務，Azure磁碟服務（Disk Storage）中的Ultra磁碟與高階SSD，Oracle Cloud的Higher Performance型區塊儲存服務等。

這類區塊儲存服務的每個磁碟，最高可提供數萬至十多萬IOPS效能，與500MB/s等級以上的傳輸率，足以與本地端的中、高階全快閃儲存陣列相比，但成本也是最高的。

● 通用型SSD

目的是為網頁伺服器、輕量型應用程式或開發測試等應用，提供兼顧效能與成本的平價SSD儲存空間，例如AWS EBS的一般用途型（General Purpose）SSD服務，Azure磁碟服務中的標準SSD，Oracle Cloud的Balanced型，以及IBM Cloud Block Storage中，每GB 2IOPS等級以上的服務等。

這類區塊儲存服務的每個磁碟，IOPS效能只有效能型SSD服務的1/3或更低，但成本也低了許多。

不過，要注意的是，一些雲端服務商的SSD型區塊儲存，並不區分為上述兩種層級，而是依照儲存區容量、區塊或執行個體來對應I/O效能的高低，如Alibaba的SSD雲端碟，Google Cloud的SSD型Persistent Disk服務等。

硬碟型區塊儲存服務

採用機械式硬碟為儲存媒體，效能只有數百IOPS的程度，最高不過1000、2000 IOPS，遠不如SSD型服務，但成本也便宜一半以上，目的是針對存取相對不頻繁、或是對效能較不敏感的應用，提供低成本儲存空間，典型的有Azure磁碟服務中的標準HDD，Goold Cloud的標準型Persistent Disk服務，Alibaba的普通雲端碟等。

比較特別的是AWS EBS，將其硬碟型區塊服務區分為：輸送量優化HDD（Throughput Optimized），以及冷HDD（Cold HDD）等兩種。前者針對普通的工作負載應用，後者則針對低存取頻率的低效能服務，效能與成本都只有前者的一半。

多面向檢視公有雲區塊儲存

我們在區分了公有雲區塊儲存的基本形式之後，接下來，我們將從效能與容量尺度、可用性、資料保護，以及資料服務功能等不同面向，來檢視當前主要的公有雲區塊儲存服務。

 相關報導  透視公有雲區塊儲存服務

儲存區規模與擴展性，也就是效能與容量，是使用公有雲區塊儲存時的頭一個問題。

為了適應用戶端環境千差萬別的應用需求，公有雲服務商都能提供多種效能層級的區塊儲存服務，以及彈性的容量選擇，包含基於硬碟的低成本儲存服務，以及基於SSD的高效能儲存服務。

藉由引進SSD作為儲存媒體，目前的公有雲區塊儲存已能提供十分可觀的效能，而且還在持續提高中。舉例來說，現今AWS與Azure區塊儲存服務的單一磁碟區最高I/O效能，都比2年前提高了3、4倍。除了提高服務效能外，引進SSD對於公有雲儲存更重要的意義，是可結合I/O效能調節技術，為用戶提供靈活按需配置、且具備「效能保證」的I/O服務品質，這是以往基於硬碟的架構難以做到的。

時至今日，SSD已經成為公有雲區塊儲存服務的主要儲存媒體，以我們這次觀察的6大公有雲服務商、一共23種區塊儲存磁碟區（Volume）型式中，超過2/3都是基於SSD。儘管如此，多數公有雲服務商仍保留了基於硬碟的磁碟區服務，向用戶提供低成本的儲存空間，也形成了豐富的儲存服務層次區分。

接下來，我們便從儲存服務的層級區分、I/O效能、容量等3個面向，來檢視主要6大公有雲服務商區塊儲存服務的尺度規格。

磁碟區效能層級區分

所有公有雲服務商，都是以效能來做為區塊服務的區分基準。目前AWS的EBS擁有最多樣化的效能層級選項，一共有：佈建IOPS SSD（Provisioned IOPS）（io1）、一般用途SSD （General Purpose SSD）（gp2）、輸送量優化HDD（Throughput Optimized HDD）（st1），以及冷HDD（Cold HDD）（sc1）等4種磁碟區層級，顧名思義，前兩者是基於SSD，後兩者是基於硬碟。

另外，AWS還保留了上一代的EBS磁帶磁碟區服務（EBS Magnetic），可提供小容量、低效能的需求。

Azure的區塊儲存服務是磁碟儲存體（Disk Storage），加上2019年中新推出的Ultra磁碟後，目前一共分為4種磁碟區層級——Ultra磁碟、高階SSD、標準SSD與標準HDD，前3者是基於SSD，最後一種是基於硬碟。

Google Cloud的區塊儲存服務永久磁碟（Persistent Disk），層級區分方式比較特別，除了基於效能外，同時還基於是否擁有遠端同步複製功能來區分，以2種基本層級——標準永久磁碟與SSD永久磁碟為基礎，再加上是否具備跨區域遠端同步複製功能，區分為區域（Zonal）型標準永久磁碟與區域SSD永久磁碟，以及擁有跨區遠端同步功能的地區（Regional）型永久磁碟與地區SSD永久磁碟，一共4種。

IBM Cloud的Block Storage服務，有兩種服務層級區分基準，首先是稱作「使用耐久性層級進行佈建」的基準，一共區分為4種效能等級——每GB 0.25 IOPS、每GB 2 IOPS、每GB 4 IOPS與每GB 10 IOPS，其中2 IOPS/GB以上的等級都是採用SSD。

另一種是稱作「使用效能進行佈建」的區分基準，有11種容量從20GB到12TB、效能從100～48000 IOPS的磁碟區。事實上，IBM Cloud的這兩種區分層級是一體兩面，容量與效能上限是一致的，多數情況下適用「耐久性層級」，如果用戶明確知道自身應用的效能需求規格，則可選用「基於效能」的佈建。

Oracle Cloud的Block Volume Service區塊儲存服務，很單純的依照效能，區分為Lower Cost、Balanced與Higher Performance等3種型式，依照Oracle說法，目前他們的新一代雲端資料中心架構，儲存服務的基礎設施都已經升級到NVMe SSD。

最後是阿里雲（Alibaba Cloud），目前可提供普通雲端碟（Basic disk）、高效雲端碟（Ultra disk）、SSD雲端碟（Standard SSD），再加上2019年初推出的ESSD（Enhanced SSD）增強型SSD雲端碟，一共有4種區塊儲存磁碟區，其中的ESSD，又分為3種等級。

除了這幾種以外，阿里雲目前正在測試另一類區塊儲存服務，即可同時供多個執行個體同時存取的共用區塊存放裝置（Shared Block Storage）。

效能規格

公有雲區塊儲存的效能，可以用IOPS、傳輸率與存取延遲等3個指標來衡量，但這是個複雜的議題，牽涉到磁碟區的大小、執行個體資源（CPU、記憶體與網路介面等）、處理資料的區塊大小，以及服務連接的物理距離等因素，因此效能指標數字只能做為粗略的參考，事實上，各服務商採用的效能計算基準也各有不同。

例如AWS EBS在io1與gp2給出的IOPS規格，是以16K I/O區塊為基準，強調IOPS表現，st1與sc1則\是以1MB區塊為基準，強調傳輸率。而阿里雲的官方IOPS規格則是以更小的4KB區塊為基準，Oracle則視不同面向使用4KB、8KB與1MB區塊為基準。

就目前來說，阿里雲的區塊儲存服務，所能覆蓋的效能區間範圍是最廣的，從數百IOPS效能的硬碟型服務，到數萬、數千IOPS等級的SSD型服務，以至10萬IOPS等級的高階SSD型服務，都能提供，甚至還有百萬IOPS等級的超高階型服務。次之的是Azure與Google Cloud，也能覆蓋到10萬IOPS等級的高階型服務。

相較下，AWS EBS的低階服務選項較多，但缺乏10萬IOPS等級以上的高階型服務，IBM Cloud與Oracle Cloud也是相似的情況。

在存取延遲方面，多數公有雲區塊儲存服務，都是以提供10ms以下的延遲為目標，一些服務則號稱可以提供更低的延遲。

容量規格

在磁碟區容量方面，各服務商區塊儲存服務的規格存在很大的差異。

AWS EBS所有服務的磁碟區容量上限都是16TB，算是目前比較小的，其中較昂貴的兩種SSD型服務io1與gp2，容量起始門檻比較低，分別為4GB與1GB；至於st1與sc1兩種硬碟型服務，雖然單位成本較低，但起始門檻也較高，為500GB起跳。

在Azure方面，除了新的Ultra磁碟以外，所有服務的磁碟區容量上限都可達到32GB，Ultra磁碟更達到64TB。在起始容量方面，Azure相對於其他服務商有著更低的門檻，SSD型服務為4GB，硬碟型服務則為32GB。

而Google Cloud永久磁碟的所有型式服務，單一磁碟區容量上限都是64TB，在起始門檻方面，沒有遠端同步複製功能的區域型（Zonal）服務，都是從10GB起跳；而附加了遠端同步複製的地區型（Regional）服務，則是從100GB與200GB起跳。

至於IBM Cloud提供的區塊磁碟區最大容量只到12TB，是目前規格較低的一種，起始門檻則是20GB。Oracle Cloud的磁碟區容量上、下限為50GB到32TB，算是中等的規格。

在阿里雲方面，除了最低階的普通雲端碟以外，其餘區塊磁碟區的容量上、下限都是20GB到32TB，而普通雲端碟則是5GB到2TB，專門對應小型應用。

 相關報導  透視公有雲區塊儲存服務

如同傳統儲存陣列平臺，公有雲的區塊儲存平臺也提供了一系列資料服務功能，來為磁碟區提供加值應用，其中最重要的資料服務功能，便是快照（snapshot）。

快照可以為磁碟區擷取特定時間下完全一致的唯讀複本，從而提供這4個面向的應用：

（1）做為災難備援，以快照複本做為備份，當原始磁碟區資料遺失或損毀時，利用快照還原磁碟區資料內容。

（2）用於資料歸檔或備份，長期保存磁碟區資料內容。

（3）用於資料遷移，在多個服務區域之間移動磁碟區資料。

（4）用於資料複製，透過快照快速產生多個原始磁碟區複本，

而公有雲區塊儲存服務提供的快照功能，屬於儲存端的快照，不會影響到前端執行個體或虛擬機器的效能。

快照雖然是一項很成熟的儲存技術，但目前各公有雲服務商區塊儲存的快照功能，在架構與功能上仍存在相當大的差異，需要注意這幾個面向：

● 快照份數限制：所有服務商都會限制快照的份數，但有些服務商是以帳號來限定快照份數，也就是某個服務區域內的某個帳號下，最多允許保存某個數量的快照（如AWS EBS、Azure與Oracle）；另一些服務商則是以磁碟區來限定快照份數，如一個磁碟區最多允許保存多少份快照（如IBM與阿里雲）。

● 快照的儲存方式：也就是快照存放的位置，以及快照的儲存是否具備冗餘性（redundancy）。

多數公有雲區塊儲存服務的快照複本，也是存放在區塊儲存服務自身的儲存區域內，但AWS EBS與Oralce Block Volume Service則不然，是將快照另外存放於物件儲存服務空間內（如AWS EBS的快照是存放於S3），以減少快照耗用的儲存成本（區塊儲存空間的成本一般略高於物件儲存空間）。

而在快照儲存的冗餘性方面，有些服務商（如AWS、Azure與Google Cloud）會將快照以多區域方式存放，讓快照複本具備更高的可用性。

● 快照的存取：一般來說，快照必須掛載到執行個體上成為磁碟區，才能讀取其中的資料，不過，AWS提供了稱作EBS Direct APIs for Snapshots的工具，可以讓用戶直接讀取位於S3儲存區中的快照複本，而無須將快照掛載起來，顯著提高了使用快照的便利性與靈活性。

● 是否支援增量式（Incremental）快照：多數公有服務商的快照功能都是增量式的，除了第一次快照為完整的複製外，後續快照都只會記錄異動的資料，從而大幅減少快照耗用的儲存空間資源。不過Azure的快照仍是完整的磁碟複製，一直到2019年中，才開始在部份地區提供預覽版的增量式快照，使用方式上也和Azure原有的快照有所差異。

● 快照加密：多數服務商都提供快照加密，原則上，只要來源端磁碟是加密的，那麼其快照複本也是加密的。

● 快照的跨區域遠端複製：部份服務商提供將快照複製到另一區域的功能（包括AWS、Azure、Google Cloud與Oracle Cloud），可藉此提供資料遷移或異地備援應用，利用將快照遠端複製到另一區域，便能在另一區域建立相同的磁碟區，構成簡單的資料擴展或異地備援應用。

● 快照的共享：一般情況下，只有同一帳號的用戶能存取快照複本，不過，AWS與Google提供了在不同帳號間共享快照的特殊功能。用戶可以將快照複本授權給另一帳號的用戶存取，從而讓其他用戶可以依據快照複本建立相同的磁碟區，而不會影響原始磁碟區，藉此提供簡便的資料分享手段。

集中備份管理的需求與解決方案

原則上，公有雲區塊儲存服務內含的快照功能，搭配快照複本的多地區存放，以及跨區域的複製功能，快照即可扮演備份的角色，無需另外使用備份產品（Oracle Cloud便直接以備份一詞，來指稱其區塊儲存的快照功能）。

問題在於，區塊儲存的快照功能只能涵蓋自身的區塊磁碟區，若用戶的公有雲應用環境，同時涉及不同類型的儲存服務（區塊、物件等）或應用軟體服務，而這些服務各有各的快照與保護功能，用戶使用上十分複雜，還是需要統一的管理工具，來集中管理這些不同服務的備份。

針對統合公有雲上不同應用服務的備份需求，AWS與Azure兩大服務商，都提供了專門的集中備份管理工具，也就是AWS Backup與Azure Backup。

其中AWS Backup，是AWS環境的備份應用集中管理平臺，可以將不同AWS服務各自既有的快照與備份功能，統合在單一管理介面下，包括EBS區塊儲存服務的快照、Storage Gateway的磁碟區快照，以及RDS資料庫與DynamoDB資料庫快照等，並為EFS提供備份功能。

透過AWS Backup主控臺即可設定自動化的備份政策，免除手動指令的需求。特別的是，由於AWS Backup也支援Storage Gateway掛載到用戶本地端的磁碟區，用戶可藉此將本地端資料備份到雲端，構成混合雲的備份應用。

Azure Backup則是Azure內含的備份軟體功能，屬於VM端的備份工具，能支援Azure自身的VM，或安裝了MARS代理程式的用戶端實體主機與Windows VM，提供整臺VM、或檔案、資料夾與系統屬性的備份，可選擇LRS本地備援儲存體或GRS異地備援儲存體，來作為備份儲存區。

 相關報導  透視公有雲區塊儲存服務

如同所有儲存設備與服務，資料儲存的可靠性，是考量公有雲區塊儲存的應用時，不可忽略的關鍵環節。如果無法確保資料儲存的可靠性，那麼公有雲儲存服務無論成本效益再高、如何地具備彈性，也難以承擔企業級的應用。

公有雲區塊儲存服務的可靠性，我們能以可用性（availability）與耐久性（durability）來衡量。

其中可用性的需求，是利用分散式儲存架構的多複本鏡像複寫機制來實現，當前所有公有雲服務商都是透過分散式架構來建構儲存環境，並透過糾刪碼（erasure coding）之類的技術，在資料中心的多個儲存節點間分散複寫資料，以防止單一儲存節點或元件的失效，從而造成資料遺失或存取中斷。

至於耐久性的需求，則是透過糾刪碼（erasure coding）與資料洗滌（Data Scrubbing）等技術的結合應用來實現，藉由持續地校驗磁碟區資料，防止資料惡化（corruption）或位元衰減（bit rod）等現象，導致磁碟區中存放的資料出現錯誤。

整體來說，目前的公有雲區塊儲存服務都能提供相當高的資料耐久性， 優於一般企業級硬碟或SSD，例如AWS EBS的年故障率（AFR）為0.1～0.2，相較下，目前最新型的SAS硬碟與SSD的年故障率規格，則為0.35～0.45%左右，這也就是說，把資料存放在AWS EBS磁碟區上，要比存放在本地端伺服器的磁碟機中更可靠。

但是，在可用性方面，公有雲區塊儲存服務的表現便平平，多數都只有99.95%或99.99%的服務等級，這意味著在一個月的使用週期中，含有多達21.5分鐘或4.32分鐘的潛在停機時間（downtime），只有AWS EBS與Azure磁碟儲存服務，可以達到更高的99.999%可用性等級，這相當於每月潛在的停機時間只有25.9秒。

整體來說，公有雲區塊儲存服務的可用性，足以因應一般的企業應用，但若是對可用性極為敏感的關鍵應用，還是以本地端的高階儲存設備較為穩當。

一般而言，用戶可以透過公有雲區塊服務內含的快照功能，來降低磁碟區不可用時造成的衝擊，能透過快照複本迅速重建失效的磁碟區。快照同樣也能幫助改善公有雲區塊服務的耐久性，當原始磁碟區出現錯誤或故障時，可從快照複本還原資料。

 相關報導 透視公有雲區塊儲存服務

為雲端運算單元提供本機區塊（Block-Level）儲存空間的區塊儲存服務，是公有雲上最基本、也最重要的儲存服務之一，這項服務自誕生以來的十多年間，無論在類型的多樣化，還是效能、可用性與資料服務功能，都有長足的進展，能因應各式各樣不同的負載與需求，是公有雲應用不可或缺的一環。我們將從6大公有雲服務商的區塊儲存出發，檢視這領域當前的現況

Google在本周釋出了支援Windows、Mac與Linux的Chrome 80桌面程式，新版有許多重要的改變，像是會自動將混合內容升級到HTTPS、強制啟用SameSite Cookie，以及提供更安靜通知介面等，同時該版也修補了56個安全漏洞。

Google是自去年12月釋出的Chrome 79起，逐步封鎖在HTTPS網頁中，以HTTP下載的內容。Google在Chrome 79封鎖了來自HTTP的腳本程式及iframe等危險的內容，而到了Chrome 80，則會自動將來自HTTP的影片及語音等內容升級到HTTPS，假設該站未提供基於HTTPS的相關內容，那麼Google也會封鎖它們。不過，使用者還是能選擇下載它們，只是會在網址列上出現不安全的圖示。

此外，Chrome 80啟用了全新的Cookie分類系統，只要是沒有宣稱可跨站使用的Cookie，其預設值都是SameSite=Lax，代表它只能在原本的網站上使用，若要跨站存取，則必須自行將Cookie設定為SameSite=None。

根據Google所列出的時程表，此一SameSite政策將在2月17日開始部署。

而新的通知設定介面則是為了避免使用者受到太多網站的通知叨擾，Chrome 80偶爾會自動秀出「請它安靜一點」（quieter）的設定介面，以讓使用者關閉通知，同時Chrome 80也會在兩種情況下主動封鎖網站的通知，一是使用者經常封鎖來自網站的通知時，二是使用者極少登入該站時。

在安全漏洞的修補上，Chrome 80總計修補了56個漏洞，當中有10個被列為高度（High）風險等級。

知名免費語音通訊軟體Discord將讀取狀態相關的程式碼，從Go轉移到了Rust。Discord軟體開發工程師Jesse Howarth在自家部落格寫道，受惠於Rust處理記憶體的機制，把讀取狀態服務實作從Go切換到Rust，極大程度地提升服務的效能。

以Rust改寫的是Discord讀取狀態服務，該服務追蹤用戶已經訂閱的頻道和訊息，當用戶連接到Discord，每次發送訊息和閱讀訊息時，都會存取讀取狀態服務，也就是說，讀取狀態是不停地被使用的程式區塊，其效能表現會直接影響整個Discord應用程式的使用體驗。

Jesse Howarth表示，為了要確保Discord用起來總是非常順暢快速，便要確保讀取狀態效能良好，使用Go實作的讀取狀態服務，在大多數的時候執行速度很快，但是每隔幾分鐘，程式就會出現大量的延遲高峰，經過Discord工程團隊調查，發現這些延遲是由Go的核心功能，包括記憶體模型和垃圾回收器所造成。

紫色線為Go，藍色線為Rust

用來儲存讀取狀態資訊的資料結構通稱為讀取狀態，整個Discord擁有數十億個讀取狀態，每個用戶每個頻道都有一個讀取狀態，每個讀取狀態具有多個自動更新計數器，用來記錄像是頻道中的提及@mentions數量等資訊。

而為了加速計數器的更新，每個讀取狀態伺服器都有讀取狀態LRU（Least Recently Used）快取來紀錄這些資訊，每個快取需要服務數百萬名使用者，而每秒會有數百萬個快取更新。為了維持持久性，Discord以Cassandra資料庫來建立快取，當快取金鑰驅逐（Eviction）時，讀取狀態便會被提交到資料庫中，且每當讀取狀態被更新時，也會被排程30秒後提交到資料庫，平均每秒會有數萬次寫入。而Discord對Go服務採樣，發現每兩分鐘就會有回應時間延遲與CPU使用率高峰出現。

之所以每兩分鐘就會有高峰出現，Jesse Howarth解釋，在Go中，當快取金鑰驅逐時，記憶體不會馬上釋放，而會等待垃圾回收器查詢，沒有受到參照的記憶體才會被釋放，也就是說，記憶體不會在閒置時立即釋放，而需要停留一段時間，當垃圾回收器確定該記憶體真正閒置之後，才會將他釋放。

由於Discord其他以Rust撰寫的部分發展越來越好，且處理讀取狀態的程式容量小且自包含，很適合移植到Rust上，因此Discord工程團隊便決定要用Rust來建構讀取狀態服務。Rust執行速度很快且記憶體效率很好，不需要Runtime或是垃圾收集器來回收記憶體，可以用來開發講究效能的服務。

Jesse Howarth提到，因為Rust沒有垃圾回收器，而是使用特殊的記憶體管理方法，該方法結合記憶體所有權的概念，Rust會追蹤讀取和寫入記憶體的程式，不再用到的記憶體會立即釋放，且因為Rust會在編譯時強制執行記憶體規則，因此在運作時，幾乎不會出現記憶體錯誤。Rust版本的讀取狀態服務，當用戶的讀取狀態從LRU快取中驅逐時，Rust便會立即釋放該記憶體，不需要等待垃圾回收器釋放。

Discord現在於許多部分都使用Rust開發，包括遊戲SDK、影片捕捉和編碼，以及部分後端服務等，現在當工程團隊在開始新專案時，也會優先考慮Rust。

圖資料庫（Graph Database）龍頭Neo4j正式發布最新版本Neo4j 4.0，主要針對企業部署，提供高可擴展性與安全性功能，Neo4j 4.0擁有過去沒有的水平擴展能力，還可以在同一叢集部署多個圖資料庫，並且採用了新的安全模型，能夠更細緻地控制資料存取的安全性與隱私性。

圖資料庫可以處理元素間的關係，提供一種快速在元素間導航的方法，以探索各元素的相關性，這使得圖資料庫非常適合用在推薦引擎上，雖然傳統表格資料庫也能處理元素關係，但是當處理的量級達數百萬個連接時，就會顯得難以應付。

Neo4j是圖資料庫領域中資源充沛的新創公司，該公司發布了免費的社群版本，以及收費的企業版本，Neo4j首席資料科學家Jim Webber提到，過去企業版在許多功能上不夠完善，而Neo4j 4.0是他們目前投入最多資源開發的一個版本，除了更具擴展性之外，也使用了新的安全性模型。

Neo4j 4.0除了垂直擴展之外，現在還支援水平擴展，Jim Webber解釋，雖然水平擴展的概念在NoSQL資料庫很常見，但是圖資料庫卻不多，但是Neo4j 4.0將可讓用戶無限制的橫向擴展資料庫，可以明顯提升效能並應付更大的流量。

而Neo4j 4.0還支援回應式程式設計，讓開發人員可以完全控制其應用程式與資料庫互動的方式，回應式系統主要的設計目標在於回應、韌性與彈性，由資料驅動且對錯誤容忍度高，特別適用於資料串流應用程式。

現在單個Neo4j叢集可以執行多個資料庫，這解決了以往要使用多個圖，必須要啟動多個伺服器或是多叢集的問題，單個Neo4j叢集中的每個資料庫，現在都有自己的安全性設定，並且獨立於其他資料庫運作，因此在同一個基礎設施中，用戶可以執行多個圖。而這個多資料庫支援，還讓用戶可以跨多個資料庫進行查詢，操作起來就像是單個有分區資料和水平擴展功能的圖一樣。

Neo4j安全性更新方面，開發人員和管理人員現在可以更全面地控制資料存取，限制特定的用戶才能看到敏感資料，新的安全框架提供一種基於使用者和角色的走訪功能，該功能可在用戶沒有讀寫權限的區域執行查詢，Jim Webber提到，當過去用戶執行查詢但是不具有走訪能力時，查詢將會丟失一半的資料，只會得到應有的一半結果。

來自PerimeterX的安全研究人員Gal Weizman，在本周對外揭露藏匿在WhatsApp中的安全漏洞，此一編號為CVE-2019-18426的安全漏洞，將允許駭客執行跨站腳本程式攻擊（XSS）或讀取受害者的本地端檔案，幸好臉書已於上個月修補了該漏洞。

根據Weizman的說明，該漏洞存在於WhatsApp的內容安全政策（Content Security Policy，CSP）中，同時影響WhatsApp的Web版客戶端程式與桌面程式。在針對Web版客戶端程式的攻擊上，駭客只要傳送一個特製的訊息就能執行XSS攻擊，而在桌面程式上，駭客則可透過XSS攻擊並繞過CSP，以讀取受害者存放在本地端的檔案，也可能執行遠端程式攻擊。

Weizman強調，CSP的規則非常重要，假設CSP的配置正確，那麼XSS的威力就會受到很大的限制，允許駭客繞過CSP等於是替駭客大開方便之門，不僅能向受害者竊取寶貴的資訊，也更容易載入其它惡意酬載。

臉書則說，CVE-2019-18426漏洞出現在WhatsApp桌面程式搭配iPhone版WhatsApp程式時，將允許XSS攻擊及讀取本地端檔案，使用者只要點選文字訊息中的預覽連結就可能受害。

最近另一個與WhatsApp有關的消息是，WhatsApp已在2月1月終止對 Android 2.3.7及之前，與iOS 8及之前等行動平台的支援，代表這些平台上的WhatsApp隨時可能停止運作，使用者只能選擇更新平台或更換手機來因應。

部份Google用戶在最近接獲Google的通知，指稱他們曾經在去年的11月21日到11月25日之間，下載包括Google Photos內容的資料，因某些技術上的問題，造成這些用戶所下載的影片可能是別人的。

根據Google的說明，在這5天之內，有些Google Photos的影片被錯誤地匯到陌生用戶的存檔中，收到該通知代表用戶的Google Photos帳號中有一個或多個影片受到影響。假如使用者下載了這些資料，那麼它們可能是不完整的，也可能包含一些不是屬於自己的影片。

Google已經解決了該問題，並建議使用者刪除之前所匯出的內容，並重新匯出一次。

9to5Google取得了Googel的官方回應，Google承認此一問題出現在用戶以Google Takeout匯出Google Photos內容時，可能會收到屬於別人的影片，同時強調該意外只影響影片內容，並未波及照片。

Nvidia從2017年就開始測試的遊戲串流服務GeForce Now，終於在本周邁入了正式版，該服務提供了免費方案與付費的Founders付費訂閱方案，後者每月的費率為4.99美元，但擁有90天的免費服務。

GeForce Now服務的基礎為Nvidia的GPU架構，讓遊戲玩家藉由網路存取效能強大的虛擬電腦，並可連結Steam、Epic Games Store、Battle.net與Uplay等遊戲服務，因此，GeForce Now標榜玩家就算使用低階裝置，都能執行需要強大效能的遊戲，涵蓋Windows筆電、MacBook、Shield或Android裝置，但要求玩家下載客戶端程式。

目前GeForce Now並未支援iOS，但Nvidia計畫在今年第一季支援Chromebook，外界預期該服務未來也可能會支援瀏覽器。

雖然GeForce Now提供了執行遊戲所需的繪圖效能，但要順暢執行遊戲的關鍵在於頻寬，該服務要求最少15Mbps的頻寬，若有30Mbps頻寬即能進行1080P的遊戲串流，而最佳體驗則需要50Mbps的頻寬。

不過，玩家最好也能離GeForce Now的資料中心近一些以降低延遲，目前Nvidia在北美設置了9個資料中心，歐洲有5個，日本有2個，韓國則有1個。

GeForce Now的免費方案提供標準存取能力與1小時的連續執行時間，付費方案則有優先存取權與延伸的執行時間。儘管媒體試用後發現該服務在上線初期有些擁擠，但對於在低階裝置上執行遊戲的效能都頗為滿意，給它的評價多半高過Google去年11月上線的遊戲串流平台Stadia。

AWS發布了適用於AWS Client VPN的桌面客戶端程式，讓Windows和MacOS用戶能夠更簡單地連線到AWS。這些應用程式可以安裝在桌電與筆電上，支援交互身份驗證，也能透過Active Directory進行帳號密碼驗證，或是多因素身份驗證。

AWS Client VPN是AWS在去年推出的服務，讓用戶可以使用OpenVPN的客戶端，從各地安全地存取AWS和企業內部網路。AWS Client VPN是一個全託管的VPN服務，企業可根據需要擴展與縮減連接數，讓員工能夠以更簡單的方式，和其合作夥伴建立連接，並透過控制臺進行控制與管理。

用戶可以使用AWS Client VPN創建客戶端VPN端點，將其與所需要的VPC子網關聯，並設定授權規則，讓用戶能夠存取需要的雲端資源。

而用戶使用這個新的客戶端程式連線VPN後，用戶的電腦便是VPC的一部分，並且可以存取授權規則所允許的資源。這個應用程式是免費提供的，企業可以用來存取AWS Client VPN端點所連結的AWS地區。

目前支援AWS Client VPN的地區有美東、美西、加拿大和歐洲，在亞洲地區，則有孟買、新加坡、首爾、雪梨和東京。

微軟又進行多項人事改組。ZDNet報導Windows用戶端部門和硬體部門合併，由Surface主管Panos Panay統轄，這項命令也有助於Windows軟、硬體整合設計。原Windows用戶端主管則調任負責Office業務。

報導指出，微軟內部於2月5日宣佈改組消息。體驗及裝置事業群下的Windows 用戶端部門，在與硬體部門合併後，改名為Windows+裝置部門，並向原任Surface主管的Panay報告，後者頭銜也改為產品長。

而長久主管Windows的Joe Belfiore，則將調任Office體驗事業群（OXO）主管。他也將持續領導負責開發Edge和iOS/Android app開發的單位Essential Products Inclusive Community。新人事命令將從2月25日生效。

根據ZDNet取得Panay的內部公開信件，Panay指出，合併Windows 用戶端部門有助於簡化決策流程，提供微軟所有連網裝置（OEM和Surface）從晶片到作業系統的最佳用戶體驗。軟、硬體一起設計將有助於提升Windows業務（包括雙螢幕產品、晶片多樣性、連網及app平台），並統一Windows用戶端產品管理及資源運用。

不過負責多項產品（如Azure、Windows用戶端、Server、Xbox或HoloLens）作業系統核心的部門COSINE（Core OS and Intelligent Edge）則未受到影響。兩年前的改組中，微軟將之整併到Azure工程部門之下。

其他變動包括現有Microsoft Teams業務主管Brian Macdonald退休，而由企業副總裁Jeff Teper兼管Teams、OneDrive和SharePoint業務。Microsoft 365主管Kirk Koenigsbauer，則成為體驗與裝置事業群營運長，輔佐執行副總裁Rajesh Jha。

此外，微軟旗下的LinkedIn執行長Jeff Weiner在執掌11年後，周四宣佈將於今年6月下台，擔任LinkedIn執行董事長，不過媒體預料是為新職做準備，他的位子由原產品長Ryan Roslansky接任。

一名俄羅斯安全研究人員Vladislav Yarmak，在本周公布了藏匿在海思（HiSilicon）晶片中的一個後門漏洞，海思半導體為華為集團旗下的晶片設計公司，估計該晶片被應用在數十萬或數百萬的連網裝置上，涵蓋監視器、數位錄影機（DVR）及網路硬碟錄影機（NVR）等，該漏洞將允許駭客取得最高存取權限，進而掌控受駭裝置。

Yarmak表示，過去海思即經常在裝置上嵌入後門存取機制，最早是啟用Telnet存取，且採用靜態密碼，只要透過少許的運算能力就能從韌體映像檔中取得密碼，之後的海思晶片韌體雖然關閉了Telnet存取及除錯傳輸埠（9527/tcp），但卻開啟了可用來接收特別指令，以開啟Telnet守護程序並存取靜態密碼的9530/tcp傳輸埠，而且所有裝置上的密碼都一樣。

至於最新的海思晶片同樣開啟了9530/tcp傳輸埠以接收特別指令，但需要執行Challenge/ Response驗證才能提交指令。不論如何修補，總是找得到途徑，使得Yarmak認為，海思是有意留下後門。

Yarmak還公布了這些監視器、DVR與NVR等裝置的後門啟動程序，並釋出概念性驗證攻擊程式，以供使用者確認自己的裝置是否含有相關漏洞。

相關漏洞影響了採用海思晶片的各種品牌的連網裝置，估計有數十萬到數百萬不等，Yarmak表示，期待海思修補漏洞是不切實際的，裝置用戶可以考慮改用其它未含漏洞的產品，或是限制裝置的網路存取能力。

研究人員發現駭客利用程式碼託管平台Bitbucket散布多種惡意程式，已經有超過50萬台電腦因此感染。

Bitbucket是由Atlassian經營的程式碼管理平台，類似GitHub。安全廠商Cybereason近日發現有駭客利用Bitbucket的合法帳號儲存並長期散布包括木馬程式、勒索軟體、採礦軟體等惡意程式。研究人員發現後立即通知Bitbucket，後者於幾小時後已將之全部移除。

研究人員指出，這波攻擊和以往攻擊最大的不同在於，過去駭客對單一目標機器是感染一次，把取得資料賣給駭客社群。但是這次，駭客對單一目標釋出多種惡意程式，以便對企業發動多種面向的攻擊。

例如攻擊者使用Evasive Monero Miner來竊取資料及挖Monero幣，用Vidar、Azorult竊取瀏覽器cookies、加密貨幣電子錢包憑證、電子郵件帳密及雙因素驗證軟體資料，用IntelRapid偷加密貨幣。他們也可用Predator拍照、擷取螢幕截圖、以AmadeyBot木馬進行事前勘查，再用Stop勒索軟體來勒索受害者。此一手法造成多重損害，而惡意程式活動也造成機器效能下降。

研究人員說，每一種惡意程式都讓這波攻擊更為強大，造成更嚴重災情。此外，駭客運用Bitbucket合法帳號上傳及散布惡意程式，為了躲避偵測，他們也提供完整的用戶資料頁並持續更新程式庫。

而以Bitbucket合法身份為掩護，駭客的確達到其目的。在持續攻擊下，研究人員估計全球感染的電腦超過50萬台。

Cybereason指出，這次發現突顯駭客利用合法雲端平台如GitHub、Dropbox、Google Drive及Bitbucket大量散布惡意軟體的犯罪趨勢，同時也顯示，駭客已經將獲取利益的手段提升到更高層次。

一名攝影師利用人工智慧（AI）技術，將一部125年前電影剛誕生時期的黑白影片畫質提升成4K畫質。

攝影師Denis Shiryaev實驗的是法國電影先驅盧米埃（Lumière）兄弟，於1895年拍攝的一部黑白短無聲紀錄片《火車進站》（L'Arrivée d'un train en gare de La Ciotat），該電影於1896年1月25日在巴黎首映。據傳當時從沒見過動態畫面的觀眾，在影片中火車向他們駛來時，嚇得倉惶走避躲到電影院後方。

這部黑白影片原始版本畫質僅640 x 480，每秒播放幀數僅 20幀（FPS）。但Shiryaev利用神經網路技術將畫質提升（upscale）到4K及60 FPS的現代化水準。

他所使用的Gigapixel AI，是由Topaz Labs發展且公開的神經網路技術。Gigapixel AI以大量圖片等資料訓練後，其演算法可以學會將低解析度的影像加入資訊，來「修正」成為高解析度圖片。這家廠商宣稱可以將解析度增強600%，讓一般數位相機拍攝的相片變成細節超清楚、銳利的100MP圖片。

另外Shiryaev還使用DAIN（Depth-Aware video frame INterpolation），這個工具能在影片中插入影格，使影片播放更加流暢。他甚至為這部默片加入音效。在第二個版本中，他又用DeOldify的技術為影片添入色彩，使這部125年前的經典影片，又在21 世紀有了新面貌。

資安業者Check Point本周揭露了藏匿在智慧燈泡Philips Hue中的安全漏洞，指稱該漏洞將允許駭客滲透到受害者的家中或辦公室網路。

研究人員表示，透過Wi-Fi或ZigBee協定控制的智慧燈泡，在3年前就證實可被入侵，允許駭客控制智慧燈泡的運作，然而，他們對於駭客能否藉由入侵IoT裝置而滲透家中、辦公室，甚至是智慧城市的網路更感興趣，也找到了攻陷之道。

準確的說，Check Point的攻擊是兩階段的，目標分別為Philips Hue燈泡與Philips Hue的橋接器，採用ZigBee協定的橋接器可用來控制所有的智慧燈泡，最多可管理50個Philips Hue。

Check Point先利用其它研究人員所開發的攻擊程式，在Philips Hue燈泡上安裝了惡意韌體，再以Philips Hue燈泡為媒介，利用橋接器上的CVE-2020-6007漏洞，取得橋接器的控制權，再滲透到受害者的網路。

在第二階段的攻擊場景中，由於駭客已可透過惡意韌體操縱燈泡的顏色與亮度，讓使用者誤以為燈泡故障了，但在行動程式中卻顯示無法存取，只得企圖重置它。而重置的方式則必須先將它從程式中移除，然後再指示橋接器發現該燈泡，此時這個已被植入惡意韌體的燈泡，則重新回到網路中。

研究人員說明，接著他們就能利用ZigBee協定的安全漏洞來傳送大量的資料，以觸發橋接器上的緩衝區溢位漏洞，以在橋接器上植入惡意程式，由於橋接器連結了受害者的家中或辦公室網路，意味著他們已成功滲透，還能展開進一步的攻擊，在受害者的網路上散布勒索軟體或間諜程式。

打造Philips Hue的為飛利浦（Philips）旗下負責照明的子公司Signify，Check Point在去年11月同時通知了飛利浦與Signify，目前該漏洞已被修補，Signify亦已更新橋接器韌體。