ドバイに拠点を置く暗号資産取引所Bybitは2月21日（現地時間）、同社のETHコールドウォレットに対する大規模なサイバー攻撃を受け、暗号資産が盗まれたと発表した。同社のベン・ジョウCEOはX上のライブストリームで、被害額は約40万1346ETHに上ると説明した。これは、当時のレートで約14億ドル（約約2100億円）に相当する。
暗号資産コミュニティや他の取引所からは、Bybitへの支持が表明されている。複数のDeFiおよびCeFi企業が、盗まれた資金の移動を阻止するために、不正なアドレスをブラックリストに登録した。ブロックチェーンデータプラットフォームを提供する米Chainalysisは、攻撃者のウォレットアドレスを追跡・公開し、業界全体の連携を支援した。
⇧ アカウントが乗っ取られて操作されたりしていたら、IPアドレスをブラックリストに登録しても効果が薄いような気がしますが、そういった懸念は無い感じなんですかね？
注目すべきは、BitMEX共同創設者のアーサー・ヘイズ（Arthur Hayes）氏などがSNSで提案した「イーサリアムブロックチェーンの巻き戻し」が、仮にコミュニティの合意が得られれば、検討される可能性があったことをチョウCEOが明らかにしたことだ。
暗号資産史上最大のハッキング事件の後、Bybit顧客は40億ドル超を引き出し──チェーンの「巻き戻し」も議論に | CoinDesk JAPAN（コインデスク・ジャパン）
注目すべきは、ブロックチェーンの「巻き戻し」とは、資金の回復を可能にする状態の変更を指すことだ。ブロックチェーンの巻き戻しは技術的には可能だが、イーサリアムブロックチェーンのスマートコントラクトによる相互作用やそのアーキテクチャを考えると、巻き戻しによる状態変更はより複雑なものになる。
暗号資産史上最大のハッキング事件の後、Bybit顧客は40億ドル超を引き出し──チェーンの「巻き戻し」も議論に | CoinDesk JAPAN（コインデスク・ジャパン）
「原因は間違いなくSafeコールドウォレット関連だ。問題が当社のノートパソコンにあるのか、Safe側にあるのかはわからない」とチョウCEOは付け加えた。
暗号資産史上最大のハッキング事件の後、Bybit顧客は40億ドル超を引き出し──チェーンの「巻き戻し」も議論に | CoinDesk JAPAN（コインデスク・ジャパン）
Safeは、暗号資産管理のためのスマートコントラクトウォレットを提供する分散型保管プロトコル。複数の取引所はSafeの機能を導入しており、資金のカストディマネジメントを行い、マルチシグ機能によってコールドウォレットのセキュリティを強化できる。
暗号資産史上最大のハッキング事件の後、Bybit顧客は40億ドル超を引き出し──チェーンの「巻き戻し」も議論に | CoinDesk JAPAN（コインデスク・ジャパン）
⇧ 仮に、「Safe」関連が原因だとしたら、「セキュリティ」強化を目的とした機能が「脆弱性」を生み出していたことになってしまい、何とも皮肉な結末ということになってしまうが...
とりあえず、
Bybit’s recent security breach has sent shockwaves through the crypto industry, exposing vulnerabilities in multi-sig cold storage solutions and emphasizing the need for more sophisticated security measures.
⇧ 脆弱性を利用されたらしいのだが、「MPC（Multi Party Computation）」への移行がシステムを堅牢にするとのことで、「MPC（Multi Party Computation）」のWikipediaの内容を見てみると、
秘匿マルチパーティ計算（ひとくマルチパーティけいさん、英:Secure multi-party computation）とは、多人数の参加者で行う秘匿計算プロトコルの総称であり、複数の参加者がそれぞれ自身の入力値を秘匿したままで多入力関数の値のみを計算することが可能となる暗号学的な手法をいう。
単にマルチパーティ計算(MPC)や秘密計算、プライバシー保護計算とも通称される。従来の暗号化手法とは異なり、このモデルの暗号化は参加者のプライバシーを相互に保護する。
歴史
特定タスク向けの特殊な目的のプロトコルは、1970年代後半に開発が始まった。その後1982年に、秘匿計算が二者間秘匿計算(2PC)として正式にブール叙述の問題で導入され、1986年には実用的なコンピュータ演算向けの一般化がアンドリュー・ヤオによって導入された。
この分野は秘匿関数評価(Secure Function Evaluation,SFE)とも呼ばれる。2者間の場合に続いてゴールドライヒ、ミカーリ、ヴィグダーソンにより多数参加者（マルチパーティ）の場合への一般化が行われた。
2000年代後半以降は、汎用プロトコルの分野が実用的アプリケーションを念頭にプロトコルの効率向上に取り組むものへと移行している。MPCにとって効率性の高まるプロトコルが提案されており、今やMPCは民間入札やオークション、署名の分散や復号関数、個人情報検索といった様々な現実的問題に対する実用的解決策だと考えられている。
2020年、秘匿マルチパーティ計算に取り組んでいる多くの企業が「MPC技術の認識、受け入れ、採用を加速する」ことを目的とするMPCアライアンスを設立した。
⇧ まだ、普及しているようには思えない...
課題は多そうではありますと...
公式のドキュメントのKubernetes構築の手順の全量が分り辛いので整理してみる
とりあえず、「AI」を全面的に信用すると仮定した上で、「Phind」で質問してみたところ、以下のような回答が得られた。
■全てに共通なシステム要件
- メモリ：2GB以上（推奨：16GB以上）
- CPU：2コア以上
- 各ノードで一意のhostname、MACアドレス、product_uuidが必要
■■スタンドアロン構成
- 要件
- 1台のみの構成
- 開発環境やテスト用途向け
■■■手順
Minikubeなどで完結できると思われるため、割愛。
■■シングルマスター構成
- 要件
- マスター1台、ワーカー1台以上
- SPOF（単一障害点）となる可能性あり
- 小規模環境向け
■■■手順
※ ノードとして仮想マシンを利用する場合、事前に仮想マシンの用意が必要と思われる。
※ yumとか利用してるので、ノードとしてRed Hat系のLinuxディストリビューションを利用している場合の手順と思われる。
| 手順番号 | 手順内容 | 手順分類 | ノード | コマンド例 | 備考 |
|---|---|---|---|---|---|
| 1 | Proxy設定 | 仮想マシン準備 | 全ノード | /etc/yum.conf編集
k8s-installer.github.io
|
インターネット接続が必要な場合のみ |
| 2 | ファイアウォール設定 | ネットワーク設定 | 全ノード | firewall-cmdコマンド
k8s-installer.github.io
|
必要ポートを開放 |
| 3 | Dockerインストール | 基盤ソフトウェア | 全ノード | yum install docker
k8s-installer.github.io
|
コンテナランタイムとして必要 |
| 4 | SELinux無効化 | システム設定 | 全ノード | setenforce 0
k8s-installer.github.io
|
セキュリティ設定 |
| 5 | Swap無効化 | システム設定 | 全ノード | swapoff -a
k8s-installer.github.io
|
kubelet動作のため必須 |
| 6 | sysctl設定 | システム設定 | 全ノード | net.bridge.*設定
k8s-installer.github.io
|
ブリッジネットワークのため |
| 7 | kubeadm/kubelet/kubectlインストール | Kubernetes準備 | 全ノード | yum install kubelet kubeadm kubectl
k8s-installer.github.io
|
Kubernetesツールのインストール |
| 8 | マスターノード初期化 | クラスタ作成 | マスターノード | kubeadm init --pod-network-cidr=192.168.0.0/16
k8s-installer.github.io
|
クラスタの初期化 |
| 9 | kubectl設定 | クラスタ作成 | マスターノード | ~/.kube/config設定
k8s-installer.github.io
|
管理者用設定 |
| 10 | Podネットワークアドオンインストール | クラスタ作成 | マスターノード | kubectl apply -f [podnetwork].yaml
k8s-installer.github.io
|
Calicoなどのネットワークプラグイン |
| 11 | ワーカーノード参加 | クラスタ作成 | ワーカーノード | kubeadm joinコマンド実行
k8s-installer.github.io
|
マスターノードから取得したjoinコマンド使用 |
| 12 | クラスタ状態確認 | 検証 | マスターノード | kubectl get nodes
k8s-installer.github.io
|
インストール完了後の検証 |
■■HA（High Availability）構成
- 要件
- マスター3台、ワーカー1台以上
- ロードバランサーが必要
- 本番環境向け
■■■手順
※ ノードとして仮想マシンを利用する場合、事前に仮想マシンの用意が必要と思われる。
※ yumとか利用してるので、ノードとしてRed Hat系のLinuxディストリビューションを利用している場合の手順と思われる。
| 手順番号 | 手順内容 | 手順分類 | ノード | コマンド例 | 備考 |
|---|---|---|---|---|---|
| 1 | Proxy設定 | 仮想マシン準備 | 全ノード | /etc/yum.conf編集
k8s-installer.github.io
|
インターネット接続が必要な場合のみ |
| 2 | ファイアウォール設定 | ネットワーク設定 | 全ノード | firewall-cmdコマンド
k8s-installer.github.io
|
必要ポートを開放 |
| 3 | Dockerインストール | 基盤ソフトウェア | 全ノード | yum install docker
k8s-installer.github.io
|
コンテナランタイムとして必要 |
| 4 | SELinux無効化 | システム設定 | 全ノード | setenforce 0
k8s-installer.github.io
|
セキュリティ設定 |
| 5 | Swap無効化 | システム設定 | 全ノード | swapoff -a
k8s-installer.github.io
|
kubelet動作のため必須 |
| 6 | sysctl設定 | システム設定 | 全ノード | net.bridge.*設定
k8s-installer.github.io
|
ブリッジネットワークのため |
| 7 | kubeadm/kubelet/kubectlインストール | Kubernetes準備 | 全ノード | yum install kubelet kubeadm kubectl
k8s-installer.github.io
|
Kubernetesツールのインストール |
| 8 | ロードバランサー設定 | クラスタ作成 | ロードバランサー | L4ロードバランサーの設定
k8s-installer.github.io
|
TCP 6443番ポートの分散が必要 |
| 9 | 最初のマスターノード初期化 | クラスタ作成 | マスターノード1 | kubeadm init --pod-network-cidr=192.168.0.0/16 --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
k8s-installer.github.io
|
クラスタの初期化 |
| 10 | 残りのマスターノード参加 | クラスタ作成 | マスターノード2,3 | kubeadm join --token <token> --discovery-token-ca-cert-hash sha256:<hash> --control-plane --apiserver-advertise-address=<IP>
k8s-installer.github.io
|
マスターノードの追加 |
| 11 | kubectl設定 | クラスタ作成 | マスターノード | ~/.kube/config設定
k8s-installer.github.io
|
管理者用設定 |
| 12 | Podネットワークアドオンインストール | クラスタ作成 | マスターノード | kubectl apply -f [podnetwork].yaml
k8s-installer.github.io
|
Calicoなどのネットワークプラグイン |
| 13 | ワーカーノード参加 | クラスタ作成 | ワーカーノード | kubeadm joinコマンド実行
k8s-installer.github.io
|
マスターノードから取得したjoinコマンド使用 |
| 14 | クラスタ状態確認 | 検証 | マスターノード | kubectl get nodes
k8s-installer.github.io
|
インストール完了後の検証 |
まぁ、「幻覚（ハルシネーション）」が起きているのかどうかの検証ができていないので、何とも言えないのですが...
公式のドキュメントはあるが...
一応、
⇧ 公式のドキュメントで、本番環境向けの構築方法について紹介があるのだが、試しに「Kubeadm」を利用した場合についての手順を確認してみても、
⇧ 必要な手順の全量が非常に分り辛い...
インフラレイヤーの知見の深いインフラエンジニアとかであれば、公式のドキュメントに掲載の無い手順を補完してKubernetes環境を構築することができるんでしょうけど、私のようなインフラレイヤーの知見の浅いソフトウェアエンジニアとしては、公式のドキュメントの手順が非常に分り辛いと思ってしまう気がするんよね...
手順通りに構築できるように、全ての手順は公式のドキュメントに記載して欲しい気はするが...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
