成功大學22日揭露學校AI研究發展藍圖，要用新增添的5臺Nvidia超級電腦DGX-1以及2年前購入的同款電腦，運用強化的運算效能，來發展成大AI學術研究，領域涵蓋醫療影像、金融科技、災害防治、自駕車，以及智慧製造等。

成大的AI發展，可從2年前說起。當時，國內尚未有大學成立獨立的AI數據中心，成大打破這個僵局，成立了人工智慧服務暨數據中心，要來支援校內各種AI研發與應用。為滿足龐大的運算需求，成大也成為全臺大學首例，引進第一臺超級電腦DGX-1。

Nvidia DGX-1搭載8張Tesla V100 GPU卡，瞄準深度學習和AI推論所需的運算效能，比起採用CPU的伺服器，快上96倍。不只效能好，DGX-1也支援Nvidia自家一系列AI軟體平臺，像是用來開發醫療影像AI的Clara平臺、開發自駕車模型的Nvidia Drive等。在部署部分，DGX-1也提供隨插即用功能，開發人員在幾分鐘內就能啟用深度學習模型。

運算效能需求劇增，6臺DGX-1緩解大量影像AI建模需求

成大電機系特聘教授暨計算機與網路中心主任詹寶珠解釋，成大龐大的運算資源需求，從30多年前就開始醞釀。她指出，自1984年成大設置醫學院以來，就與理工學院密切合作，進行各種疾病研究。這幾年，雙方更聚焦於病理、基因和放射影像領域，特別是冠狀動脈疾病、肺結核、肝癌、胃癌、大腸癌等疾病影像研究。

同時，受到AI風潮掀起，再加上累積下來的大量醫療影像資料，使成大對運算資源的需求大增。詹寶珠舉例，「我從事放射影像研究，光是一張影像就有35GB，以前根本沒人敢投入分析，因為需要大量儲存容量和強大的運算能力。」

為改善這個狀況，成大計算機與網路中心開始佈建刀鋒伺服器、全快閃儲存空間（All-Flash），「與一般硬碟儲存設備不同，All-Flash不需要找磁軌，因此讀取速度快上了100倍。」除此之外，2年後的今天，成大也導入了5臺DGX-1，要來滿足這些AI影像研究的運算需求。

詹寶珠表示，為了這次DGX-1的導入，計算機與網路中心也佈建了100Gb高速規格的交換器，「算得上是全臺第一個建置100Gb交換器的學校。」

而在導入初期，則將鎖定智慧醫療、金融科技和天然災害三大方向。在智慧醫療部分，成大與其附屬醫院目前已在腫瘤科、心臟科、放射科、重症醫學科、婦產科、腸胃消化科和急診科，導入實驗性的AI計畫。不只如此，應用於數位病理、精準腫瘤與心臟治療、E化應用介面和智慧手表的AI模型，也已導入臨床作業，現在則希望透過DGX-1來改善這些模型的訓練。

在金融科技部分，則是要強化成大與永豐銀行的AI金融科技合作應用，包括了作業流程優化、信用評估、風險評估、自然語言服務、客戶回饋分析，以及精準行銷等。

成大電機系教授暨永豐銀行技術長張天豪指出，有別於適合運算結構化資料的CPU資源，他發現，DGX-1非常適合計算影像、自然語言、語音等非結構化資料。他也語帶玄機的透露，目前與永豐銀行正在進行兩大AI專案，其中之一是利用200百萬張影像和非監督式學習來訓練AI模型，要加速過去「分行人員每天花數小時、過年要花數天才能完成的作業。」

雖然無法明講專案主題，但張天豪表示，這項AI抓案是要解決永豐銀行每天花數小時、月底需花5倍時間處理、過年更需10倍時間才能完成的重複性作業。

至於另一個專案，則與精準行銷分析有關。張天豪指出，國內3家純網銀業者最快明年開業，相較於傳統分行每天每人只紀錄幾筆交易資料，「純網銀無時無刻都紀錄著用戶的網路行為資料。」他表示，傳統銀行為追趕純網銀，希望利用這類型資料，來打造精準行銷相關應用。而現階段，張天豪透露，團隊「還在收集資料中，預計明年初完成。」

最後，在天然災害部分，成大團隊鎖定極端降雨或地震造成的山崩、土石流事件，以深度學習模型來分析，如莫拉克和蘇迪勒颱風引發的山崩，及其發生的精準時間點，來定義破壞機制和警戒值。現在要利用DGX-1來加速運算作業，以便在更短時間內處理大量數據、進行影像模擬，提高準確率。

詹寶珠總結，未來，成大希望利用DGX-1的算力，來發展更全面AI影像發展，包括醫療、自駕車、智慧製造、防災監控、智慧養殖，以及金融監控等。文◎王若樸

公有雲儲存服務問世已經超過十年，一開始只是提供雲端上的共享儲存空間，然後陸續延伸出具備不同屬性、性能與服務特性的儲存服務。到了今日，公有雲儲存無論服務的深度還是廣度，都已有很大的擴展，幾乎涵蓋企業儲存應用的所有面向。

我們可以把當前的公有雲儲存服務，分為IaaS型與SaaS型兩大類型，分別提供不同型態的應用：

IaaS型的公有雲儲存服務

目的是為用戶端或公有雲上的運算服務提供儲存空間，用戶採購的是「儲存空間」，包括物件（Object）、區塊（Block）與檔案（File）等3種基本類型，還能以這3種基本類型為基礎，搭配額外的組態與屬性功能，提供高效能存取應用、混合雲、長期歸檔儲存、加密、法規遵循等針對特定應用情境的儲存服務。

SaaS型的公有雲儲存服務

這類型公有雲儲存服務，本質上是軟體服務，而不只是單純提供儲存空間，在公有雲儲存空間的基礎上，搭配公有雲的軟體平臺，提供針對特定用途的託管型式儲存應用服務，用戶採購的標的是「軟體服務」，常見的類型包括災難備援、備份，以及資料庫等幾種。

除了這兩種基本類型外，還有一種兼具IaaS與SaaS特性的第3方儲存平臺服務，目的與IaaS型同樣都是提供儲存空間，但儲存空間是建構在第3方廠商軟體平臺上，用戶採購的是架構載特定儲存軟體平臺下的儲存空間。

提供空間的IaaS型公有雲儲存

以物件、區塊與檔案等3種基礎儲存空間服務為基礎，再衍生出針對不同應用需求的進階儲存空間服務。

3大基礎儲存空間服務

1.物件儲存服務：提供存放非結構性資料的物件儲存空間，典型的有Amazon的S3，微軟Azure的Blob Storage，以及IBM Cloud的Object Storage、Google Cloud Storage等。

2.區塊儲存服務：為用戶的雲端平臺虛擬機器，提供原始（Raw）的區塊儲存區，典型的有AWS的EBS（Elastic Block Store）、微軟Azure的Premium Storage，IBM Cloud的Block Storage，以及Google Cloud的Persistent Disk等。

3.檔案儲存服務：透過NFS或SMB協定，將公有雲的檔案系統空間，分享給雲端平臺虛擬機器（運算執行個體）使用，典型的有AWS的EFS（Elastic File System）、微軟Azure的File Storage，以及IBM Cloud的File Storage等。

5種進階儲存空間服務

1.高I/O效能應用：區塊儲存服務的高階版本，基於全快閃組態，訴求提供高IOPS效能。例如AWS EBS中最高階的io1、微軟Azure Premium Storage最高階的P80，每個磁碟可提供數萬IOPS等級的效能，阿里雲的ESSD甚至號稱可提供百萬IOPS效能。

2.長期歸檔儲存：物件儲存服務的低成本版本，為長期的資料保存需求，提供低成本的雲端儲存空間，如Amazon的S3 Glacier、微軟Azure的Archive Storage，以及Google的Archival Cloud Storage等。

3.一寫多讀（WORM）儲存：物件儲存服務的進階屬性功能，設定後可讓寫入儲存區的資料不可再被刪除或更改，以因應特定行業的資料保存法規需求。典型的有Amazon S3的Object Lock功能，以及Google Cloud Storage的Bucket Lock等。

4.加密儲存：基礎儲存空間服務的進階屬性功能，可以為整個儲存區加密，防止非授權的存取。目前大多數公有雲的區塊、檔案與物件儲存服務，都有加密選項。

5.混合雲儲存：透過公有雲服務商提供的閘道器或專屬儲存設備，連結本地端與公有雲儲存空間，構成跨本地與雲端的儲存環境，如AWS的Storage Gateway，以及微軟Azure的StorSimple。

提供軟體應用的SaaS公有雲儲存

SaaS型的服務，是以公有雲的儲存與運算服務為基礎，結合不同的應用軟體，來提供儲存類型的應用軟體服務，目前常見的有這幾種：

災難備援服務

公有雲服務商或第3方廠商提供的軟體服務，可以為用戶的雲端平臺虛擬機器環境，跨遠端建立同步的複本，並在來源端服務中斷時，自動切換由複本接手提供服務，也能利用這項服務將資料從原有區域遷移到另一區域，典型的有AWS的CloudEndure Disaster Recovery，Azure的Site Recovery等。

備份服務

由公有雲服務商或第三方廠商提供的應用軟體服務，用於備份與保護公有雲上的資料，前者如AWS Backup與Azure Backup，後者如Veeam Backup & Recovery for AWS，Cohesity Cloud Backup Service for Google Cloud等。

資料庫服務

由公有雲服務商提供的託管型資料庫軟體服務，免除用戶在本地端自行建立資料庫的麻煩。又可概分為5種主要類型：記憶體內處理式（In-Memory）、關聯式、非關聯式、時序（Time Series）資料庫，以及資料倉儲（Data Warehousing）。

以AWS為例，In-Memory類型的資料庫服務是Amazon ElastiCache，關聯式資料庫是Amazon Aurora，而非關聯式與時序資料庫服務，都是Amazon DynamoDB，至於資料倉儲服務則是Amazon Redshift。

第三方儲存軟體平臺

第三方廠商提供的應用軟體服務，為公有雲上的虛擬機器，提供基於特定儲存廠商儲存平臺的儲存空間，以取得這些儲存平臺的特性與功能，典型產品有NetApp的Cloud Volumes ONTAP與Cloud Volumes Service、HPE的Cloud Volumes，與Pure Storage的Cloud Block Store（CBS）等。

聚焦公有雲儲存的多元面向

從2016年以來，我們製作的公有雲儲存相關封面故事與專題，多集中在物件、區塊、檔案等基礎儲存空間類型的服務，而隨著公有雲服務類型與應用範圍的擴展，這一次，我們將聚焦在前述基礎類型以外的公有雲儲存服務，接下來將逐一介紹IaaS型雲端儲存服務的進階延伸功能，以及各式各樣的SaaS型公有雲儲存服務。

 相關報導 雲端儲存的多元化面貌

相對於本地端的傳統儲存設備，以往公有雲儲存的優勢主要是在成本面，藉由租賃與託管型式的服務，減輕用戶在底層儲存基礎設施的建置與維運負擔。至於在I/O效能方面，以往的公有雲儲存大多只有一般本機磁碟機層次的表現，這也制約了公有雲運行I/O密集型應用的能力。

但是到了今日，情況已經完全不同，各公有雲服務商這幾年來紛紛推出基於SSD組態的區塊儲存服務，並持續提高這類服務的效能，例如，AWS與Azure區塊儲存服務的單一磁碟區最高I/O效能，都比2年前提高了3、4倍，已能提供相當具有競爭力的效能表現，除了基於iSCSI的網路型式儲存區，近來又還有實體連接執行個體（VM）的本機型儲存區可選，可進一步改善存取延遲。

目前各公有雲服務商提供的區塊儲存服務中，最高階的等級都能提供每個磁碟數萬IOPS的效能，搭配高效能型的執行個體時，能為每個執行個體提供十多萬至數十萬IOPS效能，已能與本地端全快閃儲存陣列提供的效能相比。

其中最驚人的，是阿里雲剛於2019年初發表的高效能區塊儲存服務ESSD（Enhance SSD），透過引進NVMe SSD與25Gb RDMA傳輸架構，可以提供單一磁碟100萬IOPS的效能，還有低延遲表現（100萬IOPS下延遲500μs，50萬IOPS下延遲100μs），足以與當前最高效能 全快閃儲存陣列產品比肩，還具備公有雲的按需訂購靈活性。

這也意味著，企業用戶可透過這些高效能型公有雲儲存服務，來運行OLTP高交易資料庫等I/O密集型的關鍵應用，免除在本地端建置高效能儲存設備的必要。

 相關報導  雲端儲存的多元化面貌

不需經常存取、但需長期保存的冷資料（Cold Data）儲存應用，也就是資料歸檔或封存（Archive），是公有雲儲存服務一大發展重點，利用公有雲近乎無限擴展的特性，再結合大容量磁碟裝置，可為用戶提供低成本的雲端儲存空間，作為傳統磁帶與低成本磁碟陣列設備的替代，用於長期保存資料，以符合特定行業的法規遵循要求。

目前的公有雲長期儲存服務，都是由物件儲存服務延伸而來的低成本版本，利用物件儲存系統的擴展能力、高耐久性、可靠性、可用性，以及存取管制能力，為用戶資料的長期儲存提供安全、耐久、且具備彈性擴充能力的儲存空間。同時為了降低成本，歸檔儲存服務會再搭配限制的傳輸能力，以及有限的存取頻率，例如，歸檔儲存服務的資料取回（retrieved） 所需等待時間，一般會從標準型物件儲存服務的毫秒等級延遲，降到小時等級的延遲，存取頻率也限定為每年只存取1、2次，不過在平均月租費上，通常只有標準型物件儲存服務的1/5甚至1/10以下。

在標準型物件儲存與歸檔型物件儲存之間，由於具有不同的效能與成本特性，可讓兩者構成分層儲存架構，更有效率的管理雲端上的資料儲存。

不過要注意的是，針對長期儲存應用的歸檔儲存服務，持續儲存時間門檻要求較高，例如最少需持續儲存90天或180天，不像標準型物件儲存服務般可以隨時停止訂購，用戶每次從封存儲存區域讀取與回傳資料，也需額外收取費用。

此外，有些服務商的長期歸檔儲存服務為離線型式，收到請求時才能連接存取，而不是隨時可用。至於當用戶需要從歸檔儲存區取回資料時，發出取回、還原歸檔資料需求後所需等待的延遲時間，各服務商提供的規格也有很大差異，多數都需要數小時等級的延遲，但也少部份服務商的歸檔儲存服務，可提供秒到分鐘等級的延遲（如Google的Archival Cloud與阿里雲的Object Storage Archive）。

 相關報導  雲端儲存的多元化面貌

企業對儲存應用需求，不僅只有容量、效能、可用性或成本，同時也要求安全，某些特定行業還有符合法規的要求，因此公有雲儲存服務也提供了資料加密與WORM（Write-Once-Read-Many，一寫多讀）功能，來因應企業資料安全與法規遵循的需求。

在加密部份，目前公有雲服務商提供的儲存服務，無論是區塊、檔案還是物件儲存服務，幾乎都含有加密的選項，可以為整個儲存區加密，搭配各服務商的密鑰管理平臺，防止非授權的存取。

至於在WORM方面，這是這兩年才開始在公有雲儲存全面普及的功能，目的是確保寫入儲存區的資料不再被刪除或更改，以因應特定行業的資料保存法規需求。

目前主要的公有雲服務商，多已為物件儲存服務提供了WORM功能選項，如Amazon S3的Object Lock、Azure Blob的Immutable storage、Google Cloud Storage的Bucket Lock等。

利用這些WORM功能，可以「鎖住」特定物件的狀態，確保不被刪除或竄改。

WORM功能的啟用，分為物件儲存區的WORM屬性，以及個別物件的WORM屬性等兩個部分，用戶通常能以下列兩種方式，來管理物件的WORM屬性：

首先，是基於時間的管理方式，透過保留政策（Retation Policy）功能，設定儲存區物件被WORM「鎖住」的時間週期，到期後便可刪除：其次，是沒有時間期的「合規（compliance）」或「法務保存」（Legal hold）模式 ，直到特定稽核活動完成、並移除這個模式為止，物件都無法刪除或修改。

 相關報導  雲端儲存的多元化面貌

隨著公有雲的盛行，結合了公有雲與本地端環境的混合雲架構，也跟著普及起來。

由於本地端與公有雲分別是架構在不同的底層環境上，因此在混合雲架構下，為了便於資料與資源的統一運用，必須要透過適當的工具來連結與整合本地與雲端兩端的環境。目前已有不少廠商與工具可以提供這方面的應用需求，而我們這裡介紹的是公有雲服務商自身推出的混合雲服務，包括AWS的Storage Gateway，以及微軟Azure的StorSimple混合雲端儲存體。

顧名思義，AWS的Storage Gateway是一種閘道器服務，透過閘道器的介接，讓用戶的本地端環境可以存取AWS的S3雲端儲存空間。這項服務可以部署在實體設備、vSphere或Hyper-V虛擬機器，或AWS EC2執行個體上，並分為檔案閘道器、磁碟區閘道器與磁帶閘道器等3種版本，檔案閘道器可以NFS/SMB介面，將S3儲存空間掛載到用戶的本地端主機；磁碟區閘道器則是透過iSCSI介面，將S3儲存空間掛載到用戶本地端主機：磁帶閘道器則是雲端的虛擬磁帶櫃（VTL），可以模擬磁帶設備掛載給本地端備份軟體使用，然後將備份資料存放到S3 Glacier 或S3 Glacier Deep Archive。

Azure的StorSimple則同時兼具閘道器與儲存陣列功能，本身含有390GB到38TB的陣列儲存空間，可透過iSCSI將內部儲存空間掛載給用戶本地端主機使用，並自動依資料存取的頻繁程度，將不常用資料轉存到Azure雲端儲存空間。目前StorSimple有8000系列實體儲存陣列、雲端版Cloud Appliance，以及測試中安裝於vSphere或Hyper-V虛擬機器上的Virtual Array等3種版本，可提供30～500TB的本地+雲端混合儲存空間。

 相關報導  雲端儲存的多元化面貌

除了公有雲平臺提供的各式各樣儲存空間服務外，公有雲平臺上的資料庫應用服務，或許是對傳統儲存陣列衝擊最大的一種公有雲服務。

許多企業用戶購置中、高階儲存陣列的一大目的，便是用於運行資料庫，當公有雲平臺上有現成、合適的資料庫可用時，用戶不僅免除了自行建置資料庫的麻煩，連帶也不需要購置底層的儲存陣列。

事實上，就連老牌的資料庫系統大廠Oracle與IBM，都已在自身的雲端平臺上，提供雲端版本的資料庫，如IBM旗下的兩大老牌資料庫Db2與Infomix，目前都有位於IBM Cloud環境中的雲端版本可選。

比起用戶自行建置與維運的本地端版本，雲端版本不僅可免除用戶的系統建置與維護負擔，還具備可按需擴展或縮減的靈活性，並能利用雲端平臺提供99.99%的可用性，以及跨多個資料中心的災難備援能力。

目前公有雲平臺提供的資料庫應用服務，包含了記憶體內處理式（In-Memory）、關聯式、非關聯式、時序（Time Series）資料庫，以及資料倉儲（Data Warehousing）等幾種主要類型，大致涵蓋了當前主要的資料庫應用面向，其中傳統的關聯式資料庫選擇最多，每家服務商都有數種可選，非關聯式資料庫也已有不少類型可選，就連訴求極致效能的In-Memory類型，也已有4、5家公有雲服務商可以提供。

另外，各公有雲平臺也提供了資料庫遷移服務，幫助用戶將本地端資料庫轉移到雲端上。

我們將6大公有雲服務商提供的資料庫應用服務，簡要整理於下方圖表。

 相關報導  雲端儲存的多元化面貌

過去一年來，我們已經數次介紹過運行於公有雲上的第3方儲存平臺服務（老牌儲存平臺與公有雲環境的結合：雲端儲存陣列），不過到了下半年時，這類服務的情況也有些許變化。

這種第3方儲存平臺服務，其實就是傳統儲存廠商將其系統移植到公有雲上，成為「雲端化儲存陣列」，透過公有雲來提供儲存空間服務。

比起公有雲的原生儲存服務，老牌的儲存陣列平臺，有著用戶熟悉、系統成熟、資料服務功能完整的優點，而移植到公有雲上以後，還兼有雲端服務的維運負擔輕、按需訂購彈性。

至於將儲存陣列移植到公有雲上的方式則有兩種，一為實體部署，也就是在公有雲資料中心部署實體儲存設備。另一為軟體定義部署，也就是利用公有雲的執行個體與儲存空間，來運行儲存陣列系統軟體。

最積極發展這種「雲端儲存陣列」產品的廠商是NetApp，其ONTAP儲存平臺移植到公有雲平臺上後，成為兩種儲存服務，包括實體部署型的Cloud Volumes Service（CVS），以及軟體定義部署型的Cloud Volumes ONTAP（CVO） ，一開始是在AWS與Azure兩個平臺上，從今年下半年起，也擴展到Google Cloud。

另一重要參與者是HPE，擁有繼承自Nimble Storage的Cloud Volumes雲端儲存服務，採用實體部署型式，不過設備是部署於Equinix資料中心，再透過專屬高速網路直連公有雲服務商的資料中心，相對不受特定公有雲的束縛，具備跨多雲服務的彈性。一開始只支援AWS與Azure，從今年下半年起，也開始支援Google Cloud。

繼NetApp與HPE之後，Dell EMC與Pure Storage都在今年加入這個領域。

首先是Pure Storage的Cloud Block Store（CBS），基於其Purity//FA平臺，採用軟體定義部署型式，已於在今年9月正式上線，目前支援AWS。

接下來是Dell EMC的UnityVSA Cloud Edition，也在今年年中正式在AWS上推出，採用了一種間接的軟體定義部署方式，藉由VMware Cloud平臺的中介，讓UnityVSA Cloud Edition於AWS環境上，提供基於Unity OE平臺的儲存服務。

 相關報導  雲端儲存的多元化面貌

雲端儲存不斷延伸服務觸角，從一開始通用性的基本儲存空間服務，擴展到各式特定應用的服務，涵蓋超高I/O效能服務、資料庫、資料保護、歸檔儲存、法規遵循等面向，許多以往依靠專屬軟、硬體的特殊儲存應用需求，現在都可以在公有雲取得對應的服務

透過內含的快照複本與資料分散複製功能，公有雲儲存原則上可降低傳統備份的需要，不過若用戶的公有雲應用同時涉及不同儲存或應用軟體服務，還是需要統一的備份管理工具。

這裡介紹的是公有雲平臺自身的備份工具——AWS Backup與Azure Backup。

AWS Backup是整合不同AWS應用環境備份應用的集中管理平臺，可以統一管理不同AWS服務既有的備份功能，包括EBS與Storage Gateway磁碟區快照，以及RDS資料庫與DynamoDB資料庫快照等，並為EFS提供備份功能，透過主控臺即可設定自動化的備份政策，免除手動指令的需求。

Azure Backup是Azure內含備份功能，支援Azure自身的VM，或安裝MARS代理程式的用戶端主機與Windows VM，可以LRS本地或GRS異地備援儲存體，作為備份儲存區。

備份只提供基本的資料保護，要求更高可用性的用戶，需要災難備援工具，來提供「服務」層級保護能力。

我們這裡介紹的是公有雲自身的災難備援服務，包括AWS的CloudEndure Disaster Recovery，以及Azure的Site Recovery。

AWS的CloudEndure Disaster Recovery，可支援本地端主機、VM與公有雲上的執行個體，先在主機或執行個體上安裝代理程式，然後透過AWS上的CloudEndure伺服器作為中介，在公有雲上建立備援的伺服器與執行個體複本，並透過複製維持兩端點的資料同步。當來源端失效時，藉由CloudEndure伺服器的中介，手動或自動將服務切換到備援系統上。

Azure Site Recovery可支援本地端實體主機、vSphere與Hyper-V VM，以及雲端的Azure VM，將資料複製與同步到Azure上的備援VM，當來源端系統失效時，將服務移轉到備援系統。

 相關報導  雲端儲存的多元化面貌

現代應用程式的組成複雜，驗證與授權的流程也隨之繁複，現代框架試圖將這一切隱藏起來，但也令開發者更難以區別驗證與授權的差異。實際上，這是兩件不同的任務，既可以在單一容器中實作，在涉及第三方時，也有OAuth2、OpenID Connect等協定規範。

區別驗證與授權

事情一開始很單純，「caterpillar才能看到這個訊息」既然如此，應用程式如何驗證你真的是caterpillar？

驗證（Authentication）是證明身分（identity）的機制，例如，authenticate(name, passwd)方法定義了如何使用name與passwd進行驗證。此外，驗證方式不僅是基於名稱及密碼，也有可能基於憑證（Certificate）之類的機制。

一旦caterpillar通過驗證，就可以看到訊息，也就是說，另外有個機制決定訊息資源可否授權觀看，就像授權（Authorization）定義了身分與資源之間的存取控制規則，例如，if(authorized()) { show("message"); }這個流程，定義了"message"是否可以顯示。

在最簡單的情境中，驗證與授權可能混雜在一起，例如，「caterpillar才能看到這個訊息」，只要if(authenticate(name, passwd)) { show("message"); }就可以實現，到了這時候，authenticate()與上述的authorized()的任務就重疊了；然而，當應用程式有了一定的複雜性之後，驗證與授權的概念就會被分離開來。

例如，在Web容器當中，如果使用者驗證通過之後（authenticate()的實作傳回true），常見在Session物件中放個Token，代表已驗證，後續資源頁面判斷Session中存在Token（authorized()()傳回true），就會顯示相關的訊息資源，此時，authenticate()與authorized()，就是被分離的驗證與授權機制。

在更複雜的情況下，就必須有更複雜的驗證、授權方式，像是Java EE容器安全或Spring Security之類的框架，就定義了使用者、角色、資源等名詞，在驗證成功後，會以某方式儲存Token，其中包含角色等資訊，而在存取資源時，憑藉的是角色與資源之間已定義好的對應關係，決定是否授予資源

OAuth2授權協定

當應用程式只運行在單一容器時，使用者與資源、驗證與授權，只要在單一容器上定義或實作，就可以了；然而，若應用程式的資源是分散在多臺機器（多個容器），而且，存取每個資源前，若都要驗證，就會麻煩了。相對地，若客戶端能夠在驗證一次之後，帶著授權資訊來請求多個資源伺服器，而資源伺服器不需進行驗證，只認授權資訊來提供資源就好了。

最簡單的方式之一，就是在驗證通過後，客戶端透過HTTP基本驗證的原理，也就是透過BASIC標頭來攜帶授權資訊，然而這只適用於簡單的情境，在更複雜的場景中，需要將授權流程獨立出來，在驗證無誤之後，授權伺服器發給客戶端Access Token，客戶端再拿著Access Token向多個資源擁有者提出請求，等到資源擁有者確認Access Token合法性之後，才授予受保護的資源。

為了讓這類被獨立出來的授權流程有一致性，就有了OAuth規範。在先前專欄〈從簡單到繁複的OAuth2〉就談過，依需求的不同，目前OAuth2就規範了四種授權類型流程；不過，OAuth2本身未規範Access Token應該是什麼樣子，因此，為了增加Access Token的安全（像是避免被竄改），以及增加Token本身攜帶資訊的能力，我們可以使用JSON Web Tokens（https://jwt.io），簡稱JWT，它對Token制定了規範，具有對Token進行簽署、資源伺服器可以直接確認Token等優點。

必須區別的是，雖然OAuth2在流程中會涉及授權伺服器，授權伺服器在一開始勢必要處理驗證的問題，然而怎麼處理驗證，並不在OAuth2的規範。因為，在OAuth2的官方網站一開始也寫了，它是個用於授權的協定（protocol for authorization）。

在OAuth2結合JWT的場景中，Token中可能會帶有使用者名稱、角色等資訊，有些開發者誤以為它們是用於驗證，實際上，這些資訊是用於授權，Token中的資訊是在驗證過後才能取得；另一方面，Token只提供授權資訊，至於資源提供者收到Token後，如何運用其中資訊來決定資源的提供方式，OAuth2也不規範這塊。

簡單來說，OAuth2只是個協定，規範了授權資訊如何請求、提供，然而，並未規範如何實作驗證、如何根據授權資訊提供資源等，因為，這些是Java EE或Spring Security等安全框架的事，OAuth2與這類安全框架，基本上不存在取代的關係。

驗證協定OpenID Connect

OAuth2是第三方授權的協定規範，那麼，是否有第三方驗證的規範呢？也就是將驗證相關資訊，註冊在可信任的身分提供者（Identity Provider），在依賴方（Relaying Party）需要驗證的場合時，由身分提供者來提供身分資訊，依賴方取得身分後進行驗證，以便進一步使用依賴方的功能。例如，有些社交網站常被用來作為身分提供者，一般人可直接使用社交網站上的帳號登入，因此，這類機制常被稱為社交登入（Social login）。

曾經的OpenID 1和2是獨立的協定，也被Google、Yahoo等業者支援，然而後來有些開發者，試著使用OAuth2結合JWT，在JWT中放入驗證資訊以實現驗證（而不是授權），於是，進一步地建立了OpenID Connect（OIDC）規範（https://bit.ly/2NJYWRI）。

由於OIDC是基於OAuth2，因此，我們如果是在認識OAuth2的情況下，會比較容易理解OpenID Connect。

同時，OIDC改變了OAuth2的部份語意以用於驗證，相對於OAuth2取得的Access Token是用於授權，OIDC中的ID Token是用來驗證使用者是否為其宣稱的身分，其中也包含其他使用者資訊，ID Token使用JWT來攜帶資訊，OIDC也規範了取得ID Token後對其進行驗證的方式。

簡單來說，在OAuth2中，授權伺服器在一開始須處理驗證的問題，然而該怎麼處理驗證，並不在OAuth2的規範之中，是由OIDC補足這塊，例如，授權伺服器也許一開始用Spring Security透過資料庫進行驗證，現在可以實作AuthenticationProvider，透過OIDC從第三方OpenID提供者取得ID Token，以便進行驗證，不過，要注意的是，在驗證通過之後，授權流程等就不關OIDC的事了。

試著從規範來理解

OAuth2或OpenID Connect規範的細節很多，想瞭解並不容易，現代程式庫或框架隱藏了許多細節，只留下必要的部份給開發者設定或實作，更多時候是第三方應用程式隱藏了更多流程，只留下自己的一套設定給開發者遵守，JWT其實只是個資訊載體，其中可能包含授權、驗證資訊，或兩者皆有，這一切混淆後，就常令開發者往往搞不清楚：現在是在做驗證還是授權？

若是如此，開發者應該試著從規範來理解整個流程，釐清哪些細節被程式庫、框架或應用程式隱藏，如此一來，才能認清何時該用Java EE容器安全或Spring Security，哪時該用OAuth2，哪個地方又該採用OpenID Connect。

模型可以是各種材質做的，例如木頭、黏土、紙張、樂高積木、電子元件、數位檔案。你需要根據建模的參考對象和建模的目的來決定哪個材質最適合。

這個專欄最關心的是模型是「商業模型」和「軟體模型」，它們都是非常適合數位化建模的，而「數位化」形式具有最大的方便性，容易傳輸、容易複製、成本低、還具有未來各種可能性。現在能夠數位化，下一步就有機會自動化，再下一步就有機會智慧化。數位化的好處這麼多，我們當然用數位化形式來做我們的商業模型和軟體模型，而不是用木頭。

數位形式還有一個好處，保存方式和展示方式可以分開，一個數位保存的模型可以有多種不同的展示方式，例如財務模型可以用圓餅圖、條狀圖、表格分別從不同的觀察角度做展示。模型展現出來才能夠讓人們容易理解模型的現狀，在看到模型的現狀後進一步繼續對模型做某些操作，例如新增、刪除、修改、查詢。而模型的操作方式，可能和模型的展示方式有關。例如模型是以百分比刻度尺的方式存在，那麼調整百分比值的方式或許可以透過拖曳刻度游標的位置來做到。

如果你寫過程式，或許你已經發現，上面這段文字說的就是MVC的設計精神。MVC是Model/View/Controller的縮寫：Model是資料模型，View是展示方式，Controller（控制器）是操作方式。設計良好的軟件系統內部最好能夠把MVC三者區分開。

根據使用方式，模型可以分為二種：資料模型、程式碼模型。資料模型的建模對象通常是真實世界的事物，且資料模型在執行的過程中會不斷進行基本的新增、刪除、修改，導致模型持續的變化。程式碼模型的建模對象通常是開發者腦中的想法（演算法），程式碼模型可以被執行，且通常會關聯到其他的資料模型。正常來說，程式碼模型在執行的過程中不會改變自己的程式碼模型，但可能會改變關聯的資料模型。

模型是如何產生的，一種是我們親自建立的，例如程式碼模型；另一種是運作的過程中長時間逐漸累積建立的，例如資料模型。資料模型需要先建立（定義）一些抽象後的類型，這些類型和相關的限制規則集合起來統稱 Schema。前一篇文章我們提到的 Schema.org 名字就是這麼來的。

程式設計和技術架構設計都是在人為地、手動地建立模型，只是程式設計和技術架構設計的目的不同，而且建模的對象也不同。簡單來說，程序設計是為「功能需求」建模，技術架構設計是為「非功能需求」建模。功能需求例如：支援購物車，可以把選購的東西紀錄在裡面，以後才結帳。非功能需求例如：雙十一期間，支持最高峰一秒鐘有十萬人同時上線，系統可用率達到99.95%。

業務架構師也需要建模，建立商業模型。業務架構師建模的目的是為了「分析」業務需求本身。太多公司胡亂地決定要做哪些業務，沒有系統性地思考（也不知道該如何系統性地思考），導致資源的錯誤配置，這往往是企業內許多問題的根源。完整的商業模型分析是非常複雜的。在這個專欄中，我會介紹一個我的商業建模方法，一個很系統化的方法。

業務架構師去瞭解產品、技術、組織結構、資源、用戶、市場、競爭對手後，建立了一個完整的商業模型（Business Model），再決定要做哪些業務，並且把目標也清楚地定義在這個商業模型中，這使得我們對於未來前進的方向有了一個藍圖。根據這個商業模型的規劃，在適當的時間提出適當的需求，技術架構師和程式設計師分別去實現非功能需求和功能需求，組織架構也相應做出調整，避免成為業務和技術的絆腳石。在這個變化快速的時代，通過各種規劃和設計，盡可能地降低風險，這就是架構的意義。

Google現在於GitHub開源可配置推薦系統模擬平臺RecSim，讓用戶編寫與使用者進行順序互動的推薦系統模擬環境，突破當前增強學習應用於推薦系統，在順序互動式推薦的障礙。

Google提到，機器學習、語音辨識和自然語言處理等技術，正改變使用者與推薦系統互動的方法，在線上服務加入協同互動式推薦器（Collaborative Interactive Recommenders，CIRs），已經成為提升用戶滿意度的重要方法，不過，到目前為止，CIR系統的部署仍不普及。

雖然增強學習是解決順序決策問題的標準機器學習方法，但是CIR的研究與實作仍在發展中，Google指出，主要的障礙在於缺乏用於順序推薦器的通用模擬平臺，因為模擬是要將增強學習演算法用於諸如機器人等實際應用的主要方法。

為此，Google開發了可配置平臺RecSim，讓使用者能夠編寫模擬環境，促進像是CIR等推薦系統的增強學習演算法研究。RecSim可讓研究人員合成推薦設定，測試現存增強學習演算法的限制。Google提到，RecSim的目標是要來模擬真實推薦系統中用戶的特定行為，並作為一個受控的環境，讓開發者開發、評估和比較推薦模型和演算法。

由於RecSim是一個開源平臺，Google期望能夠藉此促進增強學習和推薦系統的交叉研究，鼓勵研究的重現與模型共享，也能讓使用者在模擬環境快速測試並修正模型與演算法，省去真正對終端使用者進行試驗的潛在成本。另外，RecSim還能在不洩漏使用者隱私的情況下，以真實的用戶行為作為學術與產業合作的資源。

Google仍在持續開發數項RecSim重要的擴充套件，包括讓程式化使用者模型（Stylized User Model）應用實際使用日誌，解決模擬到真實環境的差異，以及應用TensorFlow加速器和分散式運算，來擴大模擬與推測演算法執行。Google希望透過RecSim彌補推薦系統和增強學習研究的差距。

Bytecode Alliance提案要擴充WebAssembly的核心功能，加入多值（Multi-Value），讓函式能夠回傳多種類型的值，而這也是要為WebAssembly加入介面類型（Interface Types）的先決條件。

由於WebAssembly核心有兩個限制，第一，函式只能回傳零個或是一個值，而且諸如模塊、if和迴圈等指令序列，無法使用任何堆疊的值，並且只能產生零個或是一個結果堆疊值。多值提案則是一個標準WebAssembly的擴充，可讓函式回傳任意數量的值，而指令序列也可以使用並且產生任意數量的堆疊值。

過去當WebAssembly核心產生多種堆疊值的時候，編譯器必須要用迂迴的方式進行處理，由於WebAssembly核心限制，因此無法將值留存在堆疊中，編譯器必須要使用臨時局部變數，以及local.get和local.set等指令來操作，但這樣的方式產生了許多不必要的成本，就程式碼大小來說，多值提案可減少程式碼的量。

多值提案除了有機會能夠為產生多值加入新的指令之外，也能更有效地回傳小結構。因為沒有多值回傳，相關的小結構會暫時放置在線性記憶體中，而利用多值回傳，則這些值不會轉存在線性記憶體中，而是保留在堆疊裡，由於WebAssembly堆疊通常比線性記憶體的載入和儲存，更經過最佳化，因此這樣的操作方式效能可能更好。

另外，多值提案最重要的價值在於支援WebAssembly介面類型，WebAssembly介面類型定義了多種高階值，像是字串、序列、紀錄以及變數。而多值則能實現多種過去無法實作的案例，像是當被呼叫的WebAssembly模組能夠回傳字串，WebAssembly就能夠在網頁上，直接且以最佳化的方式存取瀏覽器DOM方法（Method）。

目前Rust和WebAssembly的工具鏈，包括相關Rust函式庫Crates都已經支援多值，方便讓Rust專案可以編譯成使用多值的WebAssembly程式碼，另外，稱為Wasmtime這個建置在Cranelift程式碼產生器的WebAssembly Runtime，現在也增加了多值支援，能夠執行使用多值功能的WebAssembly程式碼。

維基百科共同創辦人Jimmy Wales在上個月宣布，把他在2017年建立的新聞維基網站WikiTribune轉型成為社交平台WT Social，迄今一個多月的時間已有超過20萬人申請加入WT Social。

Wales表示，從他過去執行開放的協作新聞平台經驗以及不斷變化的新聞樣貌來看，促成低品質媒體的最大原因是它們完全仰賴廣告支撐，同時，散布眾多新聞的社交網路也幾乎全都依賴廣告，Facebook、Twitter與其它社交網站都是根據使用者在站上所停留的時間、觀看及點選廣告來創造營收，造成使用者的參與度更勝品質。

Wales說，全新的WikiTribune是個獨特且有點瘋狂的想法：一個可協作編輯的社交網路平台。而且一如既往，新平台將不會有任何廣告，也不會有付費牆，並賦予它一個全新的名稱WT Social。

此外，WT Social網站上開宗明義地寫著，該站將不會銷售使用者的個人資料，允許使用者選擇要提供的內容，還可直接編輯錯誤的標題，或是標記有問題的貼文，該站將推動一個可將壞份子移除的環境，不是因為這些壞份子突然觸犯了底線，而是因為這是正確的事。

由於WT Social是由小團隊經營，無法一次處理大量使用者的申請，這可能也是Wales低調發表該平台的原因，目前等待進入WT Social平台的使用者已經超過20萬人，若是推薦親朋友加入除了可加速進入該平台之外，若使用者將親友納入社團，那麼他們都會自動成為彼此的朋友。

還有另一個更快成為WT Social平台用戶的方式是捐款，只要每月捐款12.99美元或每年捐款100美元，就能立即成為WT Social用戶。

不靠廣告生存的WT Social未來將依賴人們的捐款過活，目前尚不確定此一模式能否支撐該平台的營運。

Google宣佈將在明年底正式關閉雲端列印（Cloud Print）。

Google 雲端列印讓用戶只要在裝置上安裝Chrome瀏覽器，且將印表機連結Google帳戶，就可以將手機或電腦上的文件透過Chrome列印出來。這項服務從2010年以beta版形式推出延續至今。Google支援網頁指出，從2020年12月31日起將不再支援該服務，而從後年（2021）1月1日起，所有作業系統的裝置，都無法再以Google雲端列印服務印製文件。Google建議用戶從現在開始到明年應尋找替代方案，執行移轉策略。

Google雲端列印原是因應早期印表機不支援ChromeOS而做的設計，讓Chromebooks或Chromebox用戶也能使用多數印表機來列印文件。不過Google指出，該公司已大幅改進ChromeOS的原生列印，未來也會持續強化原生列印功能，也使得ChromeOS裝置用戶用雲端列印的需求減少。而ChromeOS以外或多重OS的環境，Google建議用戶轉去相應平台的原生列印或找列印方案廠商來解決。

雖然雲端列印服務要到2020年底才除役，但Google表示，有些功能到今年底就會關閉。包括管理上千台CUPS（Common Unix Printing System，通用Unix列印系統協定）印表機、雙面／彩色列印、管理列印密碼的管理控制台、及進階列印屬性（裝印、紙盤）的支援都只提供到今年年底。同時間Google ChromeOS部門也正在開發支援CUPS-based列印伺服器及管理政策，以及匯入第三方列印工作metadata、發送列印工作API及其他管理功能等，預計在明年雲端列印服務關閉前，整合到ChromeOS中。

Business Insiders報導，臉書曾經開發一款臉部辨識app，用以辨識員工及其友人。不過臉書表示只是內部開發專案，並未用於大眾。

app專案是在2015到2016年間進行。報導引述消息人士指出，這款app某個版本只要有夠多資訊，就可以辨識出臉書平台上任何人。在測試時，只要將手機對著員工照一下，幾秒鐘之內即可辨識出員工身分並顯示臉書資料檔相片。不過這款app已經於2016年結束。

臉書上周回應CNET時坦承有這款app，但臉書說公司員工為研究新技術，經常開發app內部自己用。臉書強調這款app只限臉書員工使用，只會辨識員工及有啟用其人臉辨識功能的友人。

這項報導可能使臉書再度陷入隱私爭議。報導中提及的技術是在2018年劍橋分析案爆發之前，當時是否有臉書員工的友人身份資料及臉部相片因此被蒐集，不得而知。

2015年臉書的「標籤建議設定」使用臉部辨識技術，在用戶上傳與友人的合照時主動提供「友人」標註建議，用戶在照片中加註友人後會加入連結，連到友人的臉書資料頁。在遭到批評後，今年9月臉書推動以新的「臉部辨識設定」取代「標籤建議設定」，且預設為關閉，需用戶手動啟用，臉書才能分析用戶站上相片。

資安業者Palo Alto Networks上周警告，惡名昭彰的金融木馬Trickbot不斷地進化，本月開始鎖定OpenSSH與OpenVPN應用，企圖竊取它們的金鑰，幸好目前Trickbot功能尚未完善。

2016年現身的Trickbot專門偷竊被駭Windows上的系統資訊、登入憑證或機密資料，它是個由許多模組組成的惡意程式，其中專偷密碼的模組名為pwgrab64，可取得瀏覽器快取中存放的登入憑證，或是系統中其它應用程式的登入憑證，再透過未加密的HTTP傳送到駭客伺服器。

在電腦被植入Trickbot後，pwgrab64即可竊取來自Chrome、Firefox、IE、 Microsoft Edge、Outlook或Filezilla的機密資訊，今年初更增添可竊取憑證以利用NC、PuTTY或RDP來登入遠端伺服器的能力，現在則進一步鎖定OpenSSH與OpenVPN應用。

研究人員在今年11月發現，pwgrab64送出兩個新的請求，企圖取得OpenSSH的私鑰與OpenVPN的密碼及配置檔，而且不管受駭系統上有無安裝OpenSSH或OpenVPN都會送出請求。然而，當他們在實驗室環境中，安裝了兩台配備OpenSSH與OpenVPN應用程式的Windows 7及Windows 10電腦，再植入Trickbot時，發現pwgrab64的相關請求，並未得到任何結果。

現在的pwgrab64只能自SSH/Telnet客戶端程式PuTTY取得SSH密碼與私鑰。

主流加密貨幣之一的Monero近日傳出官網被駭，遭植入竊取用戶加密貨幣的惡意程式。一名用戶錢包裏的7,000美元等值的Monero幣，在數小時內被偷光。

上周有用戶反映他從Monero官網GetMonero下載的指令行介面（CLI）電子錢包，其二進位檔密碼雜湊值和GitHub上的版本不同，比對不成功。幾小時後，用戶發現原因不是計算錯誤，而是因為Monero官網上的版本是惡意程式。Monero證實官網上的CLI二進位檔遭到竄改，用戶下載的是惡意版本。Monero表示已經移除惡意版本，這支惡意程式總計掛在官網上35分鐘。

根據安全公司BartBlaze的分析，駭客在Monero合法檔案中注入數行新函式，可在用戶開啟或建立錢包後執行。它會將用戶錢包中的seed（即存取錢包的密鑰）傳給攻擊者設立的伺服器，使其得以竊取加密貨幣。

至少已有一名用戶受害。一名用戶透過Reddit證實他在執行程式後9小時，7,000美元等值的電子錢包全數被偷光。

Monero組織呼籲在11月18日早上2:30到下午4:30（台灣時間11月18日早上10:30到11月19日凌晨00:30）期間，曾經下載官網二進位檔的用戶先檢查檔案的雜湊值，如比對不成功則千萬不要執行檔案。已經執行者，應儘速將以該檔開啟過的所有電子錢包的錢轉到別處。Monero也公佈正確雜湊值以供比對。

行動程式分析平台Sensor Tower公布了今年第三季的全球行動程式市場調查報告，指出該季全球使用者自Google Play與App Store的程式下載次數達到296億，但當中的80%的下載量源自於1%的開發者。    

今年第三季全球約有79.2萬個程式開發者，代表7,920個程式開發者占據了236億的下載量，其它超過70萬個開發者只占60億的下載量。

若以營收來看則差異更大。今年第三季這兩大行動市集的程式營收為220億美元，它們凝聚了15.3萬個付費程式開發者，但前1%的開發者就創造了205億美元的營收，所占比例更高達93%；而其它99%的程式開發者只能爭奪剩下的7%（15億美元）營收。換句話說，這15.1萬名開發者（99%）平均每季只賺進9,900美元（約30萬元新台幣）。

若單看遊戲領域。該季全球有4.45萬個付費遊戲開發者，該類別的營收為163億美元，但前1%的開發者（445名）就賺進155億美元的營收，占遊戲總營收的96%，剩下的4.4萬名開發者共享其它營收，平均每名在該季只得到1.81萬美元的營收。

遊戲營收的前三名開發者依序是騰訊、網易及萬代南夢宮，它們在該季分別取得了20億美元、7億美元與5億美元的營收。

去年Google Play與App Store總計提供340萬種程式，但下載次數超過1,000次的程式所占比例已從2014年的30%下滑到2018年的26%，這意謂著約莫有74%的程式下載次數低於1,000次。