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