データ・ストレージとアナリティクスを提供する米国のクラウド・サービス、スノーフレークの顧客が最近、以下のような被害を受けた。 大規模な情報漏えい 史上最大になる可能性があるとも言われている。この情報漏えいは、無線通信会社AT&Tの「ほぼすべての」顧客や、チケットマスターやレンディングツリーといった他社の顧客を含む、170近い組織に影響を与えた。
しかし、今回の情報漏えいは、被害を受けた顧客や企業にとって壊滅的な打撃を与えるだけではない。クラウドの責任共有モデルが破綻した場合に何が起こりうるかを示す好例でもある。その方法を探ってみよう。
目次
セキュアなクラウドファイル転送
MASVはISO 27001/SOC 2認証を取得し、TPN検証済み（ゴールドシールドステータス）の安全なファイル転送サービスです。
📣 責任共有モデルは通常、顧客側とベンダー側の間で、データ保護と脆弱性管理の責任を明確に区分する。
ベンダーの責任と顧客の責任。単純に聞こえるだろう？
しかし問題は、実際にはプロバイダーの責任ではないデータ・セキュリティの責任を、クラウド・プロバイダーが引き受けてくれるとユーザーが思い込んでいたり、プロバイダーが提供するツールを活用していなかったりする場合だ。 (例えば、多要素認証（MFA）の実施など）。
そうなれば、セキュリティ責任の共有モデルは崩壊する。そして、データ漏洩の可能性が大幅に高まる。
AT&Tデータ漏洩事件：なぜ起きたのか？
今回のデータ漏洩は、このようなクラウド共有責任モデルの破綻が直接の原因と思われる。
このモデルを踏襲し、多くのクラウド・サービスと同様に、スノーフレークは従来、サイバーセキュリティ・ツールと機能を提供してきたが、セキュリティ態勢はユーザー自身が管理できるようにしていた。例えば、スノーフレークはMFAなどのアクセス管理ツールを提供していたが、以前はユーザーにその実施を求めていなかった。
ソース 評決.co.uk
. 略言 クラウド・サービス・プロバイダーが発表したところによると、今回の情報漏洩は「1要素認証（SFA）を利用しているユーザーを狙ったキャンペーン」であったと認めており、SFAを利用しているスノーフレーク・アカウントのパスワードは「以前に購入されたか、情報を盗むマルウェアを使って入手されたもの」であったと付け加えている。
翻訳するとキーストローク・ロギング（または類似の）マルウェアがユーザーのパスワードを採取し、それを使って安全でないスノーフレークのアカウントに侵入し、（予想通り）その中のデータを大混乱に陥れた。 しかし、スノーフレークに侵入されたアカウントの管理者が、比較的簡単な要件であるMFAアクセスコントロールをユーザー間で実施していれば、この侵入はほぼ間違いなく起こらなかったという悲しい事実がある。
(TechCrunch は最近、今回の攻撃で使用されたようなスノーフレークの顧客とされる認証情報が「何百件も」まだオンラインで入手可能であることを確認したと報告している）。
当然のことながら、情報漏えいが公表されて以来、スノーフレークは次のことを発表した。 新しい認証ポリシー 管理者は、すべてのSnowflakeユーザーにMFAを使用させることができます。
クラウドにおける企業（およびユーザー）の教訓
失敗から学ぶことはすべての人にとって重要であり、パブリック・クラウド・サービスやユーザーも同じである。
ベンダーは、管理者がMFAのような賢明なサイバーセキュリティ対策を実施できるようにしているが、この事件から学べる貴重なデータ保護の教訓は他にもある：
MFA/2FAおよびその他の賢明なセキュリティ・デフォルトを強制する。
データ侵害 は今や一般的なものとなり、ほとんどの日常的なビジネス・ユーザーでさえ、MFAや二要素認証（2FA）によるアクセス制御の重要性を認識している。管理者は常にこれを実施し、クラウド・プロバイダーは常にこのオプションを提供すべきである。
MFAは従業員に多少の摩擦をもたらすが、私は最近コンピュータを切り替えたが、設定中に数時間で約100のMFA認証に対処しなければならなかった。これだけでも、MFAを譲れない理由になる。
クラウド・サービスはまた、自動化されたプロセスに接続されているレガシー・アカウントでMFAを有効にするクライアントに対して、教育と支援を提供すべきである。
その他のセキュリティ・デフォルト、例えば、すべての新しいリソース（ストレージ・バケット、データベース、仮想マシンなど）を（デフォルトで公開するのではなく）すべてのパブリック・アクセスをブロックするように自動的に設定することも、クラウド・プロバイダーによって実装されるべきである。
この種の対策は、エンド・ユーザーに多少の摩擦を与える一方で、むしろ、よりセキュリティの高い道へと向かわせることになる。
オープン脅威情報（OSINT）の収集
顧客に代わってダークウェブや通常のインターネット上の脅威を継続的に監視し、潜在的な侵害の指標に対応する。不注意なユーザーがオープン・コード・リポジトリでAPIキーを誤って公開してしまうのは、ちょっとした伝統になっている。 GitHub上のStripe APIキー (おっと）。
クラウド企業は、オープンソースのコードリポジトリを監視し、キーリークを発見したら、影響を受けるクライアントに連絡を取るべきである。プロバイダーはこのためにCrowdStrikeのような自動化ツールを使うことができる。
潜在的な脅威に対処するためのツール提供
クラウド・プロバイダーは、DevSecOpsチームを評価し、潜在的な脅威を把握し、サイバーセキュリティのベスト・プラクティスに従うための柔軟性をユーザーに提供するために、主要なサイバーセキュリティ・プラットフォームとの統合ツールも提供すべきである。クラウド・プロバイダーがそのようなセキュリティ管理を提供していない場合、管理者はとにかくこれらのツールを探すべきである。
- 例を挙げよう：SplunkやWizのようなサービスは、クラウドインフラストラクチャ内のすべてのアクションをパッシブ監視することができる。
- もう一つの例：APIキーのローテーション。例えばユーザーが3ヶ月ごとにAPIキーを変更したい場合、プロバイダーはシステムのダウンタイムを発生させることなく変更できる仕組みを提供する必要がある。つまり、複数のAPIキーを同時に生成する機能を提供することだ。
当たり前のことを当たり前と思わない
最後に 特に顧客としては、責任共有モデルを当然と考えたり、自己満足に陥ったりしてはならない。.他社の責任だ」という考え方に陥ったり、セキュリティ・ツールが必須でなければ重要でないと思い込んだりしがちだ。
クラウド・プロバイダーは、ユーザーを責任あるセキュリティ態勢に導くために、できるだけ多くの教育と文書を提供し、同時に自社の従業員にも最新のセキュリティ脅威とベスト・プラクティスについて教育する必要がある。
そしてユーザーとしては、常にベスト・プラクティスに従い、ドキュメントを読み、書面で確認するまでクラウド・インフラ・プロバイダーが何か対処してくれるとは決して思わないことだ。
MASV：レイヤード・セキュリティ・アプローチ
強力なTLS 1.2とAES-256ベースの暗号化、厳格なアクセス制御を備えたAWSのセキュリティ上に構築されていることに加え、MASVはすべての保存データと転送データの安全性を以下の方法で維持しています。 かいそうセキュリティアプローチ を含む：
- 従業員のセキュリティ意識向上トレーニング と強力な内部パスワードジェネレーターがある。
- 製品セキュリティ 定期的なコードスキャンや管理者ログインの自動アラートを含む。
- 顧客保護 例えば、強力なパスワードの強制、MFAやパスワードジェネレータの強制的な使用の奨励などである。
- バリデーション 第三者によるサイバーセキュリティ監査と規制遵守を通じて。
MASVに登録する 今日から無料で始めましょう。
プレミアム・クラウド・インフラ
MASVは非常に安全なAWSクラウドインフラストラクチャ上で動作するため、お客様のファイルは常に安全です。