法人向けに電気料金削減のコンサルティングを提供するエネクラウド（東京都渋谷区）は5月16日、クラウド上のデータが削除される不正アクセス被害を受けたと発表した。同社は4月18日に被害の発生を公表しており、今回はその調査結果として詳細を明らかにした。AWS（Amazon Web Services）に設定していたアクセスキーが、外部から不正に使用されていたという。
クラウド狙う“削除型ランサム”被害 エネクラウドがデータ消失を公表、顧客情報漏えいの可能性も - ITmedia NEWS
被害は4月9日未明に発生。AWSのクラウドストレージ「Amazon S3」において、外部から不正に使用されたアクセスキーを通じて45件のS3バケットが削除された。同社では4月14日午前8時50分に異常を認識し、調査を開始したという。
クラウド狙う“削除型ランサム”被害 エネクラウドがデータ消失を公表、顧客情報漏えいの可能性も - ITmedia NEWS
アクセスキーの流出経路は、外部のフォレンジック調査会社による調査でも特定できなかったが、当該キーは既に無効化されている。現時点では、情報の不正流出や外部へのダウンロードの痕跡は確認されていない。同社はこの一連の事案を「暗号化ではなくデータを直接削除し、復旧の対価を要求する削除型ランサムウェア攻撃」と分析している。
クラウド狙う“削除型ランサム”被害 エネクラウドがデータ消失を公表、顧客情報漏えいの可能性も - ITmedia NEWS
⇧「Amazon S3」のAPI利用のための「アクセスキー」のことだとは思うのだが、「アクセスキー」をどう管理していたのかが分からないとどうにもならない気が...
兎にも角にも、エネクラウドにおける「アクセスキー」の管理フローが明らかにならないと、流出経路を絞り込めない気がしますな...
悪い人間が多いと管理者の負担が増えますな...
Azureにおける責任共有モデル（共有責任モデル）
Microsoftの公式のドキュメントで、
クラウドにおける共同責任
パブリック クラウド サービスを検討して評価するときは、共有責任モデルと、クラウド プロバイダーが処理するセキュリティ タスクと、処理するタスクを理解することが重要です。 ワークロードの責任は、ワークロードがサービスとしてのソフトウェア (SaaS)、サービスとしてのプラットフォーム (PaaS)、サービスとしてのインフラストラクチャ (IaaS)、またはオンプレミスのデータセンターのいずれでホストされるかによって異なります。
責任の分担
オンプレミスのデータセンターでは、お客様がスタック全体を所有します。 クラウドに移行すると、責任の一部は Microsoft に移譲されます。 次の図は、スタックのデプロイの種類に応じて、お客様と Microsoft の間の責任の範囲を示しています。
⇧ とありますと。
Azure側のメンテナンス起因の障害で利用者側が責任持つのは責任共有モデルの意味無くないか...
で、衝撃的だったのが、「Microsoft」側の「メンテナンス」起因で、「Azure リリース」を利用しているシステムで障害があったようなのだが、「利用者（Customer）」側で面倒見ないといけないって、「責任共有モデル（Azureのドキュメントでは、共有責任モデル）」の意味が無い気がしてしまうのだが...
そもそも、「Azure」における「メンテナンス」について、公式のドキュメントで説明が無いので、「メンテナンス」起因で発生した障害の「責任」が、
- メンテナンスを実施したMicrosoftが責任を負う
- 利用者側が責任を負う
のどちらが負担せねばならないのかがサッパリ分からないのだが、
⇧ とあり、そもそも「Microsoft」側が勝手に行うのであろう「メンテナンス」の全量が分からない...
ちなみに、
⇧「Azure App Service」でも「メンテナンス」が行われるようだ。
この時点で、
- Azure Virtual Machine
- Azure App Service
の最低2つの「Azure リソース」に関しては、「Microsoft」側で勝手に「メンテナンス」が実行されることが分かりましたと。
とりあえず、
Azure の計画メンテナンス イベントからの影響を受けたリソース
影響を受けるリソースを表示するエクスペリエンスをサポートするために、Service Health には次の機能があります。
- 計画メンテナンス イベントが原因で影響を受けたリソースを表示します。
- Service Health ポータル経由で、計画メンテナンスの影響を受けるリソース情報を提供する。
https://learn.microsoft.com/ja-jp/azure/service-health/impacted-resources-planned-maintenance
⇧ 上記によると、「Azure Service Health」というものが用意されているらしいのだが、
⇧ 上記の説明を見た感じでは「ヘルスチェック」のような機能を提供しているようなのだが、肝心の「利用者」への通知については、
Azure Service Health の使用
Azure Monitor を使用すると、クラウド リソースに対する可用性の変更を通知するアラートを構成できます。 受け取った通知とカスタマイズされたアラートは、特定のリソースに影響を与える問題についてあなたに知らせ、いかなる中断も迅速に通知されるようにします。
https://learn.microsoft.com/ja-jp/azure/service-health/overview
全体として、Azure Service Health は、サービスの正常性と潜在的な問題に関するタイムリーで関連情報を提供することで、Azure リソースの可用性とパフォーマンスを維持するのに役立ちます。
https://learn.microsoft.com/ja-jp/azure/service-health/overview
⇧ とあり、「Azure Service Health」は、
- Azure Status
- Service Health
- Resource Health
の3つのサービスで構成されたものと言っているのに『Azure Service Health の使用』の説明で『「Azure Monitor」を使用すると、』と説明が始まってるなどカオスなのだが...
とりあえず、「Azure Service Health」の利用は「通知先」を設定させしておけば、「メンテナンス」起因の「障害」が発生したのかリアルタイムで通知してくれるのだろうか？
もし、「Azure リソース」の「利用者」側に、
- Microsoft側のメンテナンス起因の障害
- 上記以外の障害
の判断を強制するような仕組みになっているのだとしたら、「責任共有モデル」の意味が無くないか...
「Microsoft」側の「責任共有モデル」の定義がファジー過ぎるのもあるんだが、「責任共有モデル」が機能していないんよな...
明らかに「クラウド サービス プロバイダ（CSP：Cloud Service Provider）」に該当するであろう「Microsoft」側が「責任」を放棄しているように思えて仕方ないんだが...
そもそも、クラウドのサービスを利用しているのって、
- イニシャルコストを抑制し易い
- リソースのスケールなどがし易い
- 煩雑な管理などを肩代わりしてくれる
- 責任を委譲できる
あたりが目的だったりする気がするので、「責任共有モデル」で「責任」をハッキリさせていないのは宜しくない気がするのよね...
「ミッションクリティカル（mission critical）」なシステムだと、このあたりのファジーさは致命的な気がするんだが...
とりあえず、「クラウド サービス プロバイダ（CSP：Cloud Service Provider）」は自分たちのしていることを詳らかにして欲しい気がする...
「透明性」が無いのよね...
特に、「Microsoft」に対しては、不誠実な対応の実績が枚挙に暇がないので、不信感が半端ない...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
