Skip to main content

クラウドセキュリティの基本 第1回:自社環境を把握する

2022年10月7日

0 分で読めます

ある大手金融機関から盗まれたのは、社会保障番号14万件と銀行口座番号約8万件でした。これは、2019年のことです。どのようにして起きたのでしょうか。攻撃者はファイアウォールの認証情報を使って権限を昇格させ、セキュリティ設定が不十分なAmazonのクラウドインスタンスに侵入しました。

責任ある開示プログラムを通じて金融機関に報告が寄せられると、同社は迅速に対応し、設定ミスの原因を特定して、データ窃取を可能にした脆弱性を修正しました。

この侵害は、組織が自社環境を十分に把握していないこと、そしてその知識不足が悪用される可能性を示す一例です。攻撃者がオンラインで自らの攻撃を自慢し、第三者から報告を受けるまで、組織は侵害に気づいていませんでした。これは、クラウドでは侵入検知がそれほど有効ではない理由、そして予防とセキュアな設計(自社環境の把握から始まる)が極めて重要である理由を示しています。クラウドセキュリティは、自社環境を完全に把握し、攻撃者にその情報を知られないようにすることから始まります。

自社環境を把握するためのステップ

自社環境を把握するという考え方は理解しやすい一方、実践は簡単ではありません。多くのクラウドセキュリティリーダーは、サーバーと外部の世界が分かれているという従来のセキュリティモデルを今も前提としています。つまり、脅威を検知し、進行中の攻撃を阻止すれば守れる、閉じた箱のような環境です。

しかし、クラウドはこうした前提を覆しました。AWSの開始から16年が経った今も、クラウド環境を簡単に把握できるという考えは見直す必要があります。この記事では、クラウド環境の中核から外縁まで、スタック全体を可視化する5つの方法をご紹介します。

1. クラウドSDLCを可視化する

自社環境を把握するうえで最も重要なのは、SDLCをできる限り詳細に可視化することです。クラウドファーストの環境では、チームやツールが稼働中のクラウド環境と、どのように、いつ、どこで連携するのかを明らかにします。

特に、コードリポジトリ、Infrastructure as Codeツール、CI/CDパイプラインの可視化に注力しましょう。セキュアなSDLCとは、設計、開発、デプロイだけでなく、その間にあるすべての手順、プロセス、ツールまで、各段階を漏れなく把握できている状態です。

クラウドインフラのSDLCを深く理解するほど、セキュリティを効率よく組み込めます。

2. リソースの構成情報を収集する

構成ミスは、修正にかけられる時間がほとんどないため、特にリスクが高いものです。インターネットに公開されたリソースを環境にデプロイすると、数分以内に自動化ツールを使う攻撃者候補によってスキャンされ、悪用可能な設定ミスやその他の脆弱性が探される可能性があります。コントロールプレーンの侵害は、わずか数分で実行されることもあります。そのため、セキュリティ上重要なクラウドリソースの平均修復時間(MTTR)は1時間未満を目標にすべきです。

クラウドを利用するユーザーにとって幸いなことに、クラウドプロバイダーは、環境内で稼働するすべてのリソースの構成情報を収集できるAPIを提供しています。ただし、自社環境を把握するには、APIを利用するだけでは不十分です。収集した情報を、ポリシー・アズ・コードによる自動化でクエリできる形式に整えることも必要です。そうすることで、チームは環境全体を考慮したうえでセキュリティを評価できます。

3. クラウドリソースとアプリケーションを関連付ける

エンタープライズのクラウド環境には、さまざまな種類のクラウドリソースが数十万単位で含まれることもあり、各リソースの場所や用途を把握するのは困難です。環境をより深く理解するには、クラウドリソースをアプリケーションに関連付けましょう。両者を結び付けることで、関連するアプリケーションにリスクをもたらす可能性のある脆弱なコンポーネントを、より正確に特定できます。その逆も同様です。

アプリケーションの脆弱性によってコントロールプレーンが侵害される可能性があるため、このステップは重要です。以前にもご紹介したとおり、クラウドのコントロールプレーンとは、クラウドプロバイダーが開発者に提供するAPIの集合体であり、クラウド環境の構成や管理に使われます。通常、APIキーを介してコントロールプレーンが侵害されると、攻撃者はクラウドプロバイダーのコントロールプレーンに侵入し、環境の情報をさらに収集できるようになります。これにより、システム内を横方向に移動し、より深い階層にアクセスできるようになります。

攻撃者がコントロールプレーンを侵害すると、アクセス設定や構成設定を幅広く変更できるようになります。その後、クラウドストレージやコンテナを悪用し、重要なリソースやデータを掌握する可能性があります。

4. 初期侵入に利用される脆弱性を特定する

自社環境を把握するには、自分たちの視点だけでなく、攻撃者になり得る相手の視点からも理解する必要があります。そうしなければ、玄関に複数のデッドボルトをかけながら、地下室の窓は閉め忘れている家のようになりかねません。

まず、外側から内側へと考えます。環境内のリソースを調べ、最も容易に初期侵入の足がかりとなり得るものを評価しましょう。たとえば、ある侵入がコントロールプレーンの侵害につながるかどうかを確かめるため、攻撃をシミュレーションするのも有効です。自社でレッドチームを編成する、あるいは外部に依頼する方法もあります。レッドチームとは、システムへの攻撃を模擬する権限を与えられたユーザーのグループです。

5. 攻撃経路を洗い出す

次に、内側から外側へと考えます。最も機密性の高いデータストアから出発して、逆にたどってみましょう。攻撃者がアクセスを得るために使う可能性が最も高い攻撃経路はどれでしょうか。どの侵入ポイントが最も脆弱で、そうした経路を開く可能性が高いでしょうか。

巧妙な攻撃者は、必ずしも直線的に動くとは限りません。構成設定の小さなミスによって、攻撃者が横方向に移動し、アクセス権を徐々に拡大できることがあります。自社環境を真に把握するには、どれほど遠回りであっても、攻撃者がたどり得る経路を特定する必要があります。

特に、APIキーを定期的にローテーションし、IDおよびアクセス管理(IAM)の設定とリソースアクセス ポリシーを監視しましょう。どちらも、許可範囲が広すぎる可能性があります。設定やポリシーの許可範囲が広いほど、攻撃者に悪用される可能性が高まります。

自分を知ることが、セキュリティの第一歩

クラウドセキュリティの前提となるのは、自社環境を包括的に把握し、敵対者にその情報を知られないようにすることです。最新のツールや高額なコンサルタントがセキュリティを約束しても、まず知識と可視性を確立しなければ、セキュリティのニーズを満たすことはできません。

ただし、知識と可視性は、ただ観察するだけで得られるものではありません。上記の5つのステップを実践し、クラウドシステムの可視性を意図的かつ計画的に高めましょう。

クラウドセキュリティの基盤を築く準備はできていますか?

詳しくは、クラウドセキュリティの5つの基本に関するホワイトペーパーをダウンロードしてください。

続きを読む

feature customer snowflake
Article

開発初期からセキュリティを確保:Snowflake Cortex Code向けSnyk Studioインテグレーションを発表

Snyk StudioがSnowflake Cortex Codeと連携し、開発中にAI生成コード、依存関係、コンテナの脆弱性をスキャンします。

Article

Miasmaサプライチェーン攻撃:@redhat-cloud-servicesのnpmパッケージで悪意あるコードを確認

Miasmaと呼ばれるサプライチェーンワームが、@redhat-cloud-servicesの数十件のnpmリリースで見つかりました。悪意あるpreinstallフックは認証情報を窃取し、クラウドIDを調査して、他のパッケージを再公開する可能性があります。

Blog

QinglongタスクスケジューラーのRCE脆弱性が悪用され、暗号資産マイニングに利用

Qinglongタスクスケジューリングパネルに存在する2つの認証バイパス脆弱性(CVE-2026-3965、CVE-2026-4047)が実際に悪用され、暗号資産マイニングマルウェアが展開されました。何が起きたのか、攻撃の手口、そしてセルフホスト型アプリケーションの運用者がこのインシデントから学ぶべきことを解説します。