わかりにくいバグは忘れてください。最も巧妙な脆弱性は、隠れています。
これらは、設計上のセキュリティ問題、つまりシステムの機能に固有の脆弱性です。これらはよく知られたシステムの「癖」であることが多いのですが、その影響の全体は十分に調査されていません。従来の脆弱性には行項目のコード修正が必要ですが、これらの設計上の問題には、システムの完全な再考と機能の全面的な見直しが必要になることがよくあります。
クラウド サービスの機能が業界の標準や顧客の期待から逸脱している場合、説明されている「バグ」は設計に固有のものである可能性がありますが、セキュリティに重大な影響を及ぼす可能性があります。
この記事では、影響が大きい構造的なクラウドの脆弱性について詳しく調べ、設計上のセキュリティバグの修正には単純なパッチ以上のものが必要である理由について説明します。
クラウドセキュリティにおける機能の悪用と設計上安全でない脆弱性
ここで少し時間を取って、クラウドにおけるもう 1 つの一般的なセキュリティ問題である機能の悪用、つまり機能の意図的な誤用と比較しながら、設計上安全でない脆弱性の境界を定義してみましょう。
機能の乱用：クラウド環境で認識されるリスク
機能の悪用とは、クラウド機能を利用して悪意のある目的を達成する行為を指します。これは脆弱性や欠陥を示すものではなく、正当なクラウド機能を使用する悪意を表します。
自分以外のユーザーの認証情報を生成する IAM システムの標準機能について説明しましょう。この機能は、意図的な悪用リスクが認識されているラテラルムーブ (および権限のエスカレーション) を定義します。ただし、あるユーザーが別のユーザーの認証情報を生成することを許可する IAM システムには脆弱性は存在しません。代わりに、業界では、利用可能な緩和制御を使用してこの機能の悪用を防止および検出するよう取り組んでいます。
設計上の安全性：クラウドの脆弱性クラス
業界の期待と規範は、クラウドが提供する機能を取り巻くセキュリティ制御にも適用されます。設計上安全でない脆弱性には、クラウド プロバイダーが提供する制御が不十分であることが含まれる場合があります。
上記の資格情報生成シナリオでは、サービスコンシューマーは資格情報を発行してそのようなイベントをログに記録する前に承認チェックが行われることを期待します。これらの制御がないと、顧客は重大なリスクにさらされ、サービスの設計上の欠陥が示されます。
設計上安全でない脆弱性のより具体的な例が、最近 Google’のDocumentAI サービス内で発生しました。Document AI のユーザーは、エンドユーザーがオブジェクトにアクセスできるかどうかを IAM システムが検証することなく、DocumentAI サービス エージェントの権限を使用して Cloud Storage オブジェクトをプロジェクト外に移動できました。
期待される認証チェックの欠如は、安全な設計原則からの大きな逸脱を表しています。
インセキュア・バイ・デザインの脆弱性と共有責任
ご覧のとおり、最も陰険なセキュリティリスクのいくつかは、システムの設計に直接組み込まれています。これらの設計上安全でない欠陥は、サービスの機能または利用可能な制御が確立された基準や顧客の期待から逸脱したときに明らかになります。
設計上安全でない欠陥は、サービスの不正使用を防ぐ責任が顧客にあるクラウドでは特に厄介問題です。ただし、責任共有モデルでは義務が明確に定義されているため、サービス プロバイダーは、必要な制御手段を用意し、正確なドキュメントを提供し、サービスを安全に実装するための教育を行う責任があります。
クラウドサービスにおける安全設計上の脆弱性の影響を軽減する
従来の脆弱性の修復には、多くの場合、問題のあるコードを特定し、パッチを適用し、更新を展開するという単純なアプローチが用いられます。しかし、この「修正して忘れる」という考え方では、クラウド サービスの設計上安全でない脆弱性には対応できません。なぜでしょうか。これらの脆弱性は、ソフトウェア パッケージの従来の脆弱性と 2 つの特徴で区別されるからです。
- これらの脆弱性は、多くの場合、サービスの機能と深く絡み合っており、サービスの基本的な原理を支えている場合もあるため、単純な「修正」は現実的ではありません。機能を無効にしたり、大幅に変更したりすると、無数のワークロードが中断される可能性があります。
- 常時利用可能な API では、悪用される可能性のある機能は、サービスを利用するユーザーだけでなく、API を使用するかどうかに関係なくすべての顧客に影響を与えます。
サービスを「修正」することだけに焦点を当てたゼロサム・マインドセットでは、効果的なリスク削減の選択肢は限られてしまう。その代わりに、クラウドの安全性を重視する場合は、より総合的な戦略が必要となる。これには、根本的な設計上の欠陥に対する長期的な解決策の可能性を探りながら、リスクを軽減するための予防的および検出的なコントロールを実施することが含まれる。この戦略における強力なツールの1つが、ガードレールの使用である。
コントロールの緩和：ガードレール
クラウドセキュリティにおいて、ガードレールは組織のクラウド環境全体にセキュリティ ポリシーと標準を適用する予防的制御です。ガードレールはボウリング レーンのバンパーのように機能し、使用状況が規定のパターンから大きく逸脱しないことをセキュリティ管理者に保証します。
事前に用意されたガードレールを提供することで、クラウドの脆弱性を軽減できます。ガードレールは、望ましくない動作をオフにしたり、完全に削除したりするのに特に役立ちます。ただし、安全でない機能が重要なプロセスに深く埋め込まれている場合、ガードレールの有効性は低下します。このような場合、機能へのアクセスをブロックすることは現実的ではない可能性があります。
コントロールの緩和検知とレスポンス
ガードレールのような予防的制御は有益ですが、それだけでは十分ではありません。実装は複雑になる可能性があり、正当なユースケースに対応するために例外が必要になることもよくあります。さらに、安全でない機能をすでに利用している顧客を支援するには、ガードレールや予防的制御以上のものが必要です。
そのため、安全でない機能が特定された場合、検知と迅速な対応の構築が最も価値のある修復活動となることがよくあります。
クラウド脆弱性の緩和策としての検知とレスポンス を検討する際には、以下の質問を自問自答してください。
- 顧客は違反行為の忠実度の高いシグナルを受け取るか、あるいは追加のログが必要か。
- ログはデフォルトで有効になっているのか、それとも追加ロギングを許可するために顧客に通知する必要があるのか。
- その結果に基づいて、ダメージを軽減したり取り除いたりするために迅速に行動できるか。
安全でないクラウド機能の廃止
設計上安全でない、悪用される可能性のある機能を導入すると、サービスプロバイダーにとってコストがかかる可能性があります。これらの機能は、いったん顧客のワークフローに統合されると、製品と顧客のワークロードにおける下流の依存関係や想定により、削除または変更が困難になる可能性があります。
段階的なアプローチとより安全な代替手段を導入することで、これらの脆弱性を最終的に除去または修正することは多くの場合可能ですが、そのプロセスはめったに迅速ではありません。ガードレールと検出制御が重要なのはこのためです。これらは、ビジネス プロセスを中断することなく、安全でない機能から移行するための貴重な時間を組織とその顧客に提供する、非常に必要な絆創膏として機能します。
検知 ガードレールの乱用と導入：
- 検知と予防という2つの手段を用いて、開発チームが安全でない機能から整然と移行するために必要な時間を確保する。
サンセットの機能性：
- 安全でない機能に依存している既存のワークロードを、より安全なパターンに移行する。脆弱な機能の使用を中止し、最終的に問題のあるAPIを廃止する。
クラウド脆弱性修復への運命共有アプローチ
結局のところ、設計上安全でない脆弱性に対処するには、「運命を共有するアプローチ」が必要です。クラウドプロバイダーとその顧客は、責任の相互関係を認識し、協力して取り組む必要があります。
セキュリティ制御が期待に応えられず、設計上安全でない脆弱性が生じた場合、プロバイダーは透明性を確保する必要があります。一方、顧客は、機能の不正使用を防止および検出し、安全でないレガシーパターンから環境を移行するために利用可能なツールを活用する必要があります。
この共同アプローチにより、クラウドはより回復力が高く、設計段階から セキュア・バイ・デザインシステムへと進化し続けることが保証されます。