將數據交予阿里巴巴 ODPS 大數據分析服務，會不會導致信息外泄？
如題，畢竟數據是需要放到阿里雲的計算資源上面才能做相關分析的。
2014-08-27
@pig pig
@王樂珩
「阿里自己是否會偷看或利用這些數據」 這個問題，阿里官方的回答應該是斬釘截鐵的：不會！
像很多道德和法律問題一樣，如果做有罪推定，是很難自證清白的。就好比我們說一個人會偷東西，這個人很難證明自己不會。
作為商業活動的主體，公司在這個問題上，只能表明自己的態度、所做的技術和制度上的保障、所遵循的法律。除此之外，面對有罪推定的懷疑是無能為力的。
作為用戶來說，怎麼理解和懷疑都是自己的權利，選擇信任與否是自己的自由。引申起來，面對今天所有的互聯網、電信、甚至線下的服務用戶都需要回答這個問題並做出判斷。比如，我們去飯店吃飯，我們要懷疑飯店是否用了地溝油，但我們一般不會要求飯店證明自己沒有用地溝油。面對這種問題如果太極端就可能應了那個成語：因噎廢食。總之，用戶根據服務方所做的承諾和自己所能承受的風險做出判斷就好。
---以下為原答案------------------------------------------------------------------------------
注:本回答不是想得到一個確切的結論，只是分享一點知道的信息和自己的理解。
數據放到ODPS上做分析的話，阿里肯定是可以看到數據的，但是阿里不應該試圖去解讀用戶數據，一來是因為服務協議不應該允許這樣做，二來這個成本很高，用戶的數據在ODPS里都是以資料庫表的結構存在，要理解這些數據需要人為分析用戶業務，而且用戶數據的價值未必值得這麼做。
所以，題主的問題可以等價於：將自己公司的數據上傳到ODPS並進行分析是否會導致數據泄漏給除阿里之外的第三方？
ODPS通過API提供服務，包括數據上傳、下載、計算，所以這些API就是用戶和ODPS服務的邊界。因為引入ODPS，用戶自己的流程中也可能產生數據泄漏，比如管理問題，這就需要對現有流程做改造，保證能接觸到數據的人在數據流入ODPS之前不會產生泄漏。接下來就可以分析ODPS本身。
從平台設計和技術實現角度說，ODPS比較充分的考慮了數據安全性，ODPS團隊對於平台的優先順序定義是數據安全性大於可用性大於規模的。具體包括但不限於:所有API請求都是經過認證的，認證基於阿里雲賬號;所有API請求都可以走https加密，包括數據上傳、下載，防止網路竊聽；所有請求都有細粒度的許可權檢查；用戶提交的程序運行在沙箱中，這是對系統本身的保護也是對用戶數據的保護。
當然，技術上的安全是相對的，沒有絕對的安全。在系統存在漏洞，甚至管理存在漏洞的情況下都有可能導致數據泄漏，這個就得靠信心和SLA來保證了。把數據放到Google bigtable，Amazon S3也是一樣的。
這個問題本身還有另一種理解，就是ODPS會不會導致阿里自己的數據泄漏。
阿里自己是有一部分數據包括關聯公司的數據在ODPS上的，所以這部分數據的安全等級和外部用戶的是一樣的。
利益相關: 阿里員工，前ODPS團隊成員
ODPS設計之初就是面向多租戶，確保租戶的數據安全是ODPS的必備功能之一。在ODPS系統的安全設計和實現上，ODPS的工程師們會遵循一些經過實踐檢驗的安全設計原則（如Saltzer-Schroeder原則）。在常用密碼演算法及安全協議的設計和實現上，也會遵循業界相關標準（如PKCS-及FIPS-系列標準），並堅持最佳安全實踐。
這裡從如下幾個方面來解刨一下ODPS的安全特性，讓關心ODPS數據安全的讀者有一個基本的了解。
1. API認證
認證是一個服務的安全入口。ODPS認證採用業界標準的API認證協議來實現，如HmacSHA1。ODPS還提供HTTP和HTTPS兩種的EndPoint以滿足用戶對認證安全的不同要求。HTTP EndPoint是明文傳輸，那麼HmacSHA1認證只能保證消息請求的真實性(Authenticity)和完整性(Integrity)，適合於對數據安全不太敏感的用戶。HTTPS EndPoint則能提供更多的安全性，比如信道加密，抗重放攻擊等。適合於對數據安全比較敏感的用戶。
2. 訪問控制
當你創建項目空間後，你就是項目空間的owner。一個項目空間只有一個owner，只有owner對項目空間有完全控制許可權。你可以上傳/下載數據、提交SQL進行數據處理。在沒有你的授權的情況下，任何其他用戶都無權訪問你的項目空間。 注意，ODPS平台並沒有超級管理員的角色，所以ODPS的開發、測試、運維同學都是沒有許可權看到用戶數據的。有人會問了，通過ODPS背後的運維管理控制台也不能訪問用戶數據嗎？的確不能。運維同學只有在獲得內部授權之後，可以通過該控制台來執行一些運維管理類操作，比如停止一個有惡意行為的用戶作業，但該控制台沒有操作用戶數據的許可權。
ODPS產品面向的是企業級用戶，所以提供了豐富的項目空間內的用戶管理及授權功能，有興趣的同學可以參考ODPS用戶手冊中的相關章節。ODPS訪問控制粒度非常精細，比如你可以授權一個用戶只能讀某個table的部分columns，並且可以要求該用戶只能在某個時間範圍內、而且必須從指定的某些IP地址來進行訪問。換句話說，一個企業主可以做到只允許其員工在公司內、在正常上班時間才能訪問數據，下班回家就不允許訪問了。
3. 數據流控制
ODPS設計之初就是要滿足數據分享（或數據交換）的場景。所以，只要有授權，用戶就可以非常方便的進行跨項目空間的數據訪問。比如，在獲得相應的訪問許可權之後，項目空間A中的作業可以直接處理項目空間B中的數據，而不必事先將數據從項目空間B中複製到項目空間A。
數據保護有兩層含義，一是防止未授權的數據訪問；二是防止獲得授權的用戶濫用數據。很多商用系統並不提供後一種數據安全保證。但在ODPS平台上，用戶的這種擔憂比較明顯：用戶希望能確保對自己的數據擁有控制權，而一旦授權他人讀取，他人就可能會做複製數據，那麼就相當於失去了對數據的控制權。
ODPS通過支持數據流控制來防止跨項目空間的數據複製。如果你想確保項目空間中的所有數據都不允許流出去，那麼你可以打開項目空間的數據流控設置。你還可以設置項目空間的數據保護策略，以限制哪些數據可以流出到哪些項目空間。
4. 用戶作業的隔離運行
ODPS支持用戶提交各種類型的作業（如SQL/XLib/MR）。為了確保不同用戶作業在運行時互不干擾，ODPS將用戶作業的Worker進程運行在飛天 Container沙箱中。如果用戶作業含有Java代碼（比如UDF），那麼飛天Container沙箱中的Worker進程啟動JVM時，還會設置嚴格的Java 沙箱策略以限制UDF的運行時許可權。
5. 作業運行時使用最小許可權
最小許可權原則是系統安全和容錯設計的一個基本指導原則，即讓每個任務在運行時使用剛好滿足需要（不多也不少）的許可權來執行。
ODPS的作業運行過程一般是這樣：用戶提交的SQL/XLib/MR作業會被調度到某一計算集群上運行，運行時每個作業一般對應一組並行跑的Worker進程，Worker進程一般會從數據集群上讀數據、處理完成後最終會將數據寫回到數據集群。舉個例子來理解ODPS是如何遵循最小許可權原則的。我們假設用戶Alice被授權讀訪問一個項目空間下t1和t2兩個table數據，但她提交的某個SQL只需要讀t1的數據。在ODPS中，這個SQL對應的Worker進程在運行時就只能讀t1對應的底層數據文件，而不會有更多的數據訪問許可權。
ODPS最小許可權是依賴於底層的飛天分散式操作系統提供的Kerberos認證和Capability訪問控制來實現的。Kerberos認證用於解決飛天底層服務模塊之間的身份認證，Capability則用於解決底層服務模塊之間的訪問控制技術。這與上層ODPS所提供的認證和訪問控制是完全正交的安全機制，對ODPS用戶是完全透明的。
6. 數據訪問審計
ODPS還提供精準的、細粒度的數據訪問操作記錄，並會長期保存。ODPS平台體系所依賴的功能服務模塊非常之多，我們可以把它稱之為底層服務棧。對於數據操作記錄來說，ODPS會收集服務棧上的所有操作記錄，從上層table/column級別的數據訪問日誌，一直到底層分散式文件系統上的數據操作日誌。最底層分散式文件系統上處理的每一次數據訪問請求，也都能追溯到是最上層的哪個項目空間中的哪個用戶的哪個作業發起的數據訪問。
有了服務棧上的各層操作審計之後，即使是內部攻擊者（工程師或滲透到內部系統中的黑客）想從內部（繞過ODPS服務）直接訪問底層分散式文件系統上的用戶數據的話，也一定是可以從操作日誌中被發現的。所以，通過數據訪問審計，用戶就可以準確的知道他在ODPS上的數據是否存在未授權的數據訪問。
7. 風險控制
除了不同層面的防禦機制之外，ODPS產品還會提供一套安全監控系統，用於監控用戶作業及用戶數據的安全活動，如AccessKey濫用，項目空間安全配置不當，用戶代碼運行時觸犯安全策略，以及用戶數據是否遭受異常訪問等。
安全攻擊防不勝防，所以ODPS會通過安全監控手段來及時發現問題，一旦發現安全問題則會啟動相應的處理流程，儘可能將用戶損失降到最低。
結語：雖然沒有絕對的安全，但安全性在ODPS產品設計和實現中享有最高優先順序。ODPS團隊已經匯聚了多領域的安全專家，以保障用戶數據安全。同時，我們歡迎更多安全專家的加入，共同增強ODPS的數據安全。
首先，阿里肯定有規定，來表示阿里公司不會偷看用戶的數據。
其次，這也只是規定罷了，出於利益考慮，阿里公司或者其員工肯定也必須會查看或利用這些數據。
最後，阿里泄密的事情還少么？自己百度一下吧，一堆一堆的。----------
更新：喲，王樂珩 這貨居然把我屏蔽了，哈哈，評論戳中了你們阿里巴巴的痛點了吧？
看你這個外泄是怎麼定義，外泄最重要的問題是要分清楚泄密對象，你的數據放到阿里去，那麼阿里一定知道你的數據的，如果這個算外泄，那麼不可避免，那如果是除了阿里之外的第三者，這個就要看阿里的安全做的如何了，原則上阿里的安全一定比自己做靠譜，但是如果您的數據不想給阿里，自己搭一個hadoop集群最靠譜，最好這個集群不上網，只能內部訪問
首先，從根子上而言，你是否信任服務提供商？這個問題的答案很簡單，如果發生服務商竊取數據的事件，它的損失是不是比你大。以前回答過一個問題 租用伺服器、空間、VPS、雲設施等是不是無法避免被服務提供商竊取數據？可以參考。
阿里雲產品官網有一個安全白皮書，供你參考： http://imgs-storage.cdn.aliyuncs.com/help/yunanquan/%E9%98%BF%E9%87%8C%E4%BA%91%E5%AE%89%E5%85%A8%E7%99%BD%E7%9A%AE%E4%B9%A6%EF%BC%88%E4%B8%AD%E6%96%87%E7%89%88%EF%BC%89%E5%8F%91%E5%B8%83%E7%A8%BF2014%E5%B9%B41%E6%9C%88.pdf
然後，ODPS做了大量安全和許可權方面的工作，我不算最了解的，稍後可以請專家上來講一下。@pig pig
@王樂珩
@shellc
1- 說實話，我不相信中國公司的操守，尤其是在巨大的利益與誘惑之前。
2- 更重要的是，要考慮你的數據是否敏感，是否重要。不敏感，不重要的數據可以用啊。
Tips：我之前也使用亞馬遜的大數據分析服務，我把那些敏感，重要信息都刪除或者做了保護，
再發給大數據分析服務。
3- 如果公司有實力，就自己建吧。我們公司就是在自己的數據中心上加了私有雲。
PS. 有人會問我：為什麼不太相信中國公司的操守，卻相信國外公司？
- 國外有完善的法律，更重要的是國外公司不太敢違法，或玩擦邊球- 你相信在一個連嬰兒奶粉都能出事的時代，我們數據安全的那點破事有人會關心嗎？
阿里數據安全要求所有阿里員工不能使用第三方雲存儲服務(網路直接屏蔽)，包括不限於印象筆記、百度雲、有道筆記、微軟雲、google docs等等，作為中國雲計算領頭羊，對雲服務的態度尚且如此，中國雲服務安全信任環境的構建還任重道遠。
啊喲，我們有嚴格規定的啦，請放心，不過疑者恆疑，我只能舉例啦，。最直白的支付寶這麼多錢啊，貸款都用到阿里雲，這數據阿里木有丟失吧……企鵝的域名都是在阿里雲做解析，我們也木有亂來的啦
一般來說，應該是安全的，密級較高的數據還是建議放到本地
這取決於你的數據有沒有價值呀。
如果沒人惜得看你的數據，就不會外泄。如果有人覺得有用，能賣錢，就一定外泄。
阿里支付寶自己的數據都被人弄出去過，能保護你的數據，你信嗎？反正我是不信。
阿里應該不會泄露給第三方，但如果數據接入成本合適，而且有用的話可能會自己用來做阿里自己的數據積累吧，比如你這是個比較有價值的徵信數據，我覺得阿里會很開心的收下完善自己的資料庫的，但肯定不會再給別人的。
可以用本地加密啊。
雲端只存加密後數據不就可以了嗎
從來不覺得阿里會很有節操地不泄漏你的秘密，這種事他們還幹得少了嗎。。
推薦閱讀：