幣安們的「48 小時」能為幣圈帶來什麼啟示?

之後世界最大虛擬貨幣交易所之一、來自北京的 OKcoin 創辦人徐明星在員工群裡表示,「未來隨時準備捐給國家」。
評論
Photo Credit: Make-someones-day
評論

本文來自合作媒體 Pingwest,INSIDE 授權轉載

2018 年 3 月 7 日,注定是被幣圈銘記的一天。

凌晨,幣安被傳出故障。駭客盜取幣安帳戶,至少捲走了 7 億元。

緊接著 7 日一早,美國證券交易委員會(SEC)發佈公告,提醒投資者注意數位化資產交易的非法平台,並表示對此類交易平台的監管行動趨嚴。SEC 稱:「這些交易平台提供交易資產的機制,必須符合聯邦證券法對‘證券’的定義。如果平台提供證券數位資產交易服務,並按照聯邦證券法規定下的‘交易所’營運。」

然後,日本金融廳連發 8 道「肅清令」,開出 7 張罰單,2 家交易所被直接關停,5 家被要求整改。

一日之內,一連串偶然事件,所有幣圈人都被卷涉其中,人心惶惶。

3 月 9 日,世界最大虛擬貨幣交易所之一、OKcoin 創始人徐明星在員工群裡表示,「未來隨時準備捐給國家」。

幣安事件始末

故障發生在深夜。

3 月 7 日凌晨 1:40,數位貨幣交易所幣安(Binance)被爆出現故障。

多名使用者在論壇發帖稱,幣安疑似遭到駭客攻擊,突然拋售他們帳戶內的加密貨幣。他們發現自己幣安帳戶中的各種代幣、數位貨幣被即時交易成 BTC。據媒體的報導和分析,這是一場有組織、有預謀的駭客行動。故障源於部分 API 機器人被駭客攻擊。駭客利用盜用的帳號高價買入 VIA(維爾幣),導致 VIA 被拉爆至,漲幅 110 倍。

幣安立即宣佈暫停所有幣種提現。但駭客並沒有選擇提現,而是在幣安上拉高 VIA 的幣值,引發其它交易所幣價的連鎖反應,駭客再從其它交易所掛好的空單中漁利。

然而幣安官方回應:「沒有被盜,API 提現要 Mail 確認,只是被賣出,現在情況已經制止住了,幣提不走的,在確認為什麼這些使用者出問題。」

被盜者想要回滾交易,但幣安表示因交易對手不是駭客帳號,無法回滾交易,損失將由使用者自行承擔。

幣安是目前交易量排名第二的虛擬貨幣交易所,僅次於 OKEx。此次安全故障不僅導致幣安可信度直線下降,而且讓各大交易所備受質疑。「在中心化的交易平台玩去中心化的區塊鏈虛擬貨幣,本身就很諷刺。」有網友稱。

據 CoinMarketCap.com 統計,受此次事件波及,排名前十的數位貨幣全線下跌,數位貨幣陷入持續普跌局面。

3 月 8 日上午九點,幣安在官網發佈公告稱,已恢復提現,並表示這是一次大規模通過釣魚獲取使用者帳號並「試圖」盜幣事件。

「門頭溝」的教訓

幣安是世界上第二次大規模盜幣事件。

4 年前的「門頭溝」事件,直接導致當時世界最大的交易平台倒閉。

門頭溝,即 Mt.Gox 的中譯名,曾經最大的比特幣交易網站,總部位於日本東京,創立於 2010 年。

當時比特幣方興未艾。由於參與早、競爭少,Mt.Got 一度佔據全球比特幣交易量 80% 市場。

2014 年 2 月 7 日,Mt.Got 發佈公告稱,發現大量無效提現請求,需要分析原因,隨即暫停了一切提現操作。這瞬間給比特幣世界帶來極大恐慌。多個知名比特幣交易網站先後宣佈暫停提現,比特幣價格一度腰斬。

3 天後,Mt.Gox 發出公告稱已查明原因,提現交易受到「偽造交易 ID 攻擊」,罪魁禍首是「交易延展性漏洞」。簡單來說,就是駭客申請提取貨幣,在受到交易所支付的比特幣後修改交易 ID,讓交易所誤以為交易失敗,重新發送比特幣。

這樣,駭客就會收到雙倍數量的比特幣。

根據一份名為 Mt.Gox 危機管理草案的檔案,Mt.Gox 當時一共丟失了投資人大約 75 萬枚比特幣,時價約為 3.65 億美元。最後,由於資不抵債,Mt.Gox 只好申請破產。

關於失竊原因,大家眾說紛紜。有人說 Mt.Gox 確實遭受到駭客攻擊,也有人說是交易所監守自盜,將投資人的比特幣佔為己有,賣給其他平台。

無論是哪種原因,受害者都是比特幣的投資者們。交易所可以收取交易手續費,亦可通過爆倉止損,或者像 Mt.Got 一樣跑路。而投資者,卻要為交易所的錯誤買單。

事實上,交易所一直是駭客攻擊的富礦,近日全球頻頻傳出交易所失竊新聞。今年 1 月 26 日,日本加密交易所 Coincheck 被駭客入侵,580 億日元新經幣被竊;2 月 11 日,意大利加密貨幣交易所 BitGrail 價值 1.7 億美元的 Nano 幣被盜。

在炒幣者眼裡,除了幣價大跌的威脅,最忌憚的恐怕就是駭客的入侵了。無論天災人禍,投資者都只能望洋興嘆。

駭客們吃定大家的,就是很多國家並不會將虛擬貨幣失竊立案,在法律的真空地帶,他們肆無忌憚地進攻掠奪。

美、日、中監管部門接連發聲

3 月 8 日,美國「證監會」證券交易委員會(SEC)發佈公告,提醒投資者注意非法數位資產交易平台。

關於數位資產交易的潛在非法線上平台的聲明

線上交易平台已經成為投資者購買和出售數位資產的主流方式,包括對數位貨幣和 ICO 代幣的買賣。這些平台聲稱能夠讓投資者快速購買和出售數位資產。許多平台充當買賣資訊的中介和撮合商,為投資者們提供能夠報價、交易執行和交易數據等自動化系統

這些交易平台提供交易資產的機制,必須符合聯邦證券法對「證券」的定義。如果平台提供證券數位資產交易服務,並按照聯邦證券法規定下的「交易所」營運,那麼該平台必須在 SEC 註冊為全國證券交易所或申請豁免註冊資格。制定該聯邦監管框架是為了保護投資者,並防止欺詐和操縱交易行為。

投資者使用網上交易平台的注意事項

為了在交易證券數位資產時獲得由聯邦證券法和 SEC 監管提供的保護,投資者應使用在證券交易委員會註冊的平台或實體,例如國家證券交易所,替代交易系統(「ATS」)或經紀商。

證券交易委員會的工作人員擔心,許多線上交易平台在投資者看來是 SEC 註冊和受監管的市場,但其實不是。許多平台稱自己為「交易所」,這可能會給投資者造成誤解,認為他們受到監管或符合國家證券交易所的監管標準。雖然其中一些平台聲稱以嚴格的標準挑選高資訊的數位資產進行交易,但這些標準或者平台選擇的數位資產並未經過 SEC 審查,而且所謂的標準不等同於國家證券交易所標準。

同樣,美國證券交易委員會也沒有審查這些平台所使用的交易協議,但這些協議確定了訂單如何互動和執行,而且對些使用者而言,每個訪問平台交易服務可能都不一樣。再次,投資者不應該假設交易協議符合美國證券交易委員會註冊的國家證券交易所的標準。最後,許多這樣的平台給人的印象是,他們通過提供訂單等資訊的更新來執行類似於交易所的功能,但沒有理由相信這些資訊與國家證券交易所提供的資訊一樣完整。

鑒於上述情況,投資者在決定線上交易平台上交易數位資產之前,應該問一些問題:

  • 你在這個平台上交易證券嗎?如果是這樣,該平台是否被註冊為國家證券交易所?
  • 平台是否作為 ATS 運行?如果是這樣,ATS 是否註冊為經紀商,並已向 SEC 提交 ATS 表格?
  • Brokercheck 裡是否有關於營運該平台的任何個人或公司的資訊?
  • 該平台如何選擇數位資產進行交易?
  • 誰可以在平台上交易?
  • 什麼是交易協議?
  • 如何在平台上設置價格?
  • 平台使用者是否平等對待?
  • 平台的費用是多少?
  • 平台如何保護使用者的交易和個人身份資訊?
  • 什麼是平台對網絡安全威脅的保護,比如駭客攻擊或入侵?
  • 該平台提供了哪些其他服務?平台是否在美國證券交易委員會註冊了這些服務?
  • 平台是否擁有使用者的資產?如果是這樣,這些資產如何得到保護?

其實,監管的出現,對交易所和虛擬貨幣交易所而言並非壞事。有業內人士表示,將虛擬貨幣和證券相提並論,這等於是變相承認虛擬貨幣的商品地位。

事實上,類似於幣安的問題,在全球都有發生。交易所本身並不安全,不斷經受駭客的襲擊。這已經不再是是否去中心化的問題,而在於現行的交易規則並不是對所有人都是公平的。駭客可以盜幣、莊家能坐莊、交易所可以爆倉,每一條都有讓普通投資者的帳戶清空的可能。

在 SEC 發佈聲明幾乎同一時間,日本金融廳連發 8 條肅清令,成立「虛擬貨幣交易從業者研究會」,關停 2 家交易所,5 家交易所被要求整改。

日本是最先提出對數位貨幣交易所監管的國家。當年的「門頭溝事件」直接催生日本政府制定了相關法規,如《銀行法修訂案》等。而且早在 2016 年,日本政府為了防止恐怖主義和洗黑錢等違法行為,簽署了《資金結算修正法案》,將虛擬貨幣正式納入法律體制內。

導致日本金融廳本次整頓動作的原因,恰好又是一家交易所漏洞導致的。不久前,日本交易所 Coincheck 被盜走約 580 億日元的數位貨幣。竊案發生後,日本金融廳對所有加密數位貨幣交易所展開安全漏洞相關調查,結果發現,這些交易所在客戶保護和反洗錢措施上存在漏洞。

又是在同一天,在北京舉辦的十三屆全國人大一次會議新聞中心舉辦的記者會上,中國人民銀行行長周小川在回答記者有關虛擬貨幣的問題中表示:

「在考慮新技術同時,在服務的方向上要清楚,我們不太喜歡創造一個可投機的產品,讓人都有一夜暴富的幻想,要想怎麼服務實習經濟,數位貨幣要給消費者和市場帶來效率、低成本、安全、隱私保護,還要考慮大局,不要與現行金融秩序相衝突。」

周小川沒有透露央行對數位貨幣未來的監管細則,但指明瞭一些方向:

未來的監管是動態的,取決於技術成熟程度……我們不太喜歡創造可投機的產品,讓人有一夜暴富的幻想,這不是一件好事。你想搞數位貨幣,要是個消費者零售市場帶來效率、低成本、安全隱私的考慮,另外要考慮大局,不要與現行的金融穩定金融秩序直接的相衝突。但如果你技術發展對原有的金融秩序帶來改變,也需要比較慎重的研究慎重再走。

先是日本,再是 SEC,不出意外的話接下來會是中國,三大主要國家的動向,意味著數位貨幣交易所有望被納入現行的證券框架之內。這種監管和引導,對數位貨幣未必是一件壞事——這將遏制目前交易所存在的種種亂象,更加有效地保護投資者的權利。

不過,監管的向好信號對提振市場情緒似乎沒有起到作用。3 月 8 日晚,幣安、OKEx、火幣網 pro 和 bitmex 等虛擬貨幣交易所出現無法訪問或速度緩慢的情況,引發外界對中國監管「一刀切」的猜測。第二日,全球虛擬貨幣價格普遍大跌,比特幣價格一度跌至 9000 美元以下,情狀慘烈。

9 日,OKcoin 創辦人徐明星在其員工群稱「已向領導做了彙報」,並表態「隨時準備把交易所交給國家」,又一次引發圈內震動。

那麼,2018 年的虛擬貨幣市場會多一份清淨和透明嗎?


開發者享受 CI/CD 價值!運用 Amazon EKS 整合 GitLab 創建自動化部署

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?
評論
評論

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

打造第一個在 AWS 上的應用程式

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

透過 AWS 增加雲端技能 在組織發揮影響力

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!