次の脅威モデルを作成する際におそらく含めるべきもの

DisruptOps では現在、脅威モデルの作成に取り組んでいます。そこで、さまざまなアプローチについて知識を改めて整理することにしました。すぐに目についたのは、私がこれまで見てきた脅威モデリングのドキュメントやツールのほとんどが、CI/CD パイプラインを対象に含めていないという点です。

これは。明らかに。問題です。 脅威モデルにはパイプラインを含めてください。

ここ数年、私はさまざまなアドバイザリー業務に加えて、数十件のクラウドセキュリティ評価を直接実施してきました。その際は常に開発／デプロイのパイプラインを対象範囲に含めていますが、比較的大きなセキュリティ上の問題が見つかるのは、多くの場合こうしたパイプラインです。どこかにあるテンプレートを変更したり、保存された鍵を侵害したりするだけで基盤インフラを改変できるのであれば、厳重に保護したはずのクラウド環境も砂上の楼閣にすぎません。

脅威モデルの多くは、データフロー図やアーキテクチャ図から始まります。これらを使ってアプリケーションを順にたどりながら脅威をモデル化していきます（私自身は Microsoft 発の STRIDE を好んで使っています）。ただし、これで網羅できるのはアプリケーションの機能であり、パイプラインは含まれません。

パイプラインに対して *その時々の* 脅威モデルを適用する場合は、開発者や管理者をユーザーとして扱ってください。また、パイプライン自体が認証情報を保持しているのであれば、それがどのように環境へ接続しているかを考慮したうえで、パイプラインもユーザーとして扱ってください。

たとえば、Jenkins への API 呼び出しを偽装して、本番アプリケーションに変更を加えることは可能でしょうか（Jenkins の一般的な設定では、おそらく可能です）。ジョブの変更とコードの変更に関する否認についてはどうでしょうか。パイプライン内での権限昇格は防げるでしょうか。

パイプラインはセキュリティの観点から精査すると、あまり耐えられないことが多いため、今後のセキュリティの基本に関する投稿で取り上げる予定です。私がリスク低減のために、パイプラインのデプロイと接続されたインフラの両方にガードレールを設けることを推奨しているのは、おそらく驚くにはあたらないでしょう。たとえば、CI サーバーは公開されるべきでも、公開できる状態にあるべきでもありません。インターネットゲートウェイのないネットワークセグメントに配置されていること、かつ セキュリティグループがパブリックアクセスを許可していないことを、相互補強型のガードレールで確実にすることができます（さらに望ましいのは、CI サーバーを常にエラスティックロードバランサーの背後に配置することです）。

アプリケーションの攻撃対象領域がその構成要素だけに限られていた時代は、とうに終わりました。クラウドでは、ほとんどのアプリケーションがパイプラインによって支えられており、広範なアクセス権と保存された認証情報を持つパイプラインは、極めて脆弱な急所になりかねません。