本ブログでは、セッショントークンを狙ったサイバー攻撃の増加傾向について、最近の注目事例を交えてご紹介します。また、オンラインでセキュアなクラウド開発環境（CDE）を活用することで、DevOpsプロセスをこうした脅威からどのように強化できるかを解説します。
増大する脅威：セッショントークン窃取の危険性が高まるサイバー攻撃
セッショントークンなどの認証情報を狙ったサイバー攻撃が急増しています。
たとえば、2023年1月に発生したSlackのGitHubリポジトリからのソースコード漏洩事件、同じく2023年1月のCircleCIのインシデント、さらに2022年4月のGitHubアカウントの侵害、2022年12月のOktaの事例など、高度な攻撃が立て続けに報告されています。これらのケースは、セッショントークンを標的とした攻撃の増加傾向を示すものです。
本ブログでは、この攻撃手法を簡単に振り返るとともに、オンラインでセキュアなクラウド開発環境（CDE）を活用することで、DevOpsプロセスをどのように保護し、堅牢なDevSecOps基盤を構築できるかをご紹介します。
OAuth攻撃：セッショントークン窃取はどのように行われるのか？
セッショントークンの窃取は、多くの場合、フィッシング攻撃の成功によって引き起こされます（以下の図のステップ1を参照）。
攻撃者は、被害者のデバイスにマルウェアを感染させ、そのマルウェアがトークンの窃取を実行します。
感染後、マルウェアは以下の方法でセッショントークンを盗み出します：
- クライアントとサーバー間でトークンが送信される際に、その通信を傍受する
- クライアント側のアプリケーションに悪意のあるコードを注入し、ユーザーのデバイスから直接トークンを抜き取る
その後、盗まれたトークンは攻撃者が管理する外部のサーバーに送信されます。これがステップ2〜5にあたります。
攻撃者がセッショントークンを手に入れると（ステップ6および7参照）、多要素認証（MFA）を回避し、不正なセッションを開始できるようになります。
これにより、機密情報へのアクセスだけでなく、ターゲットアプリケーション内での権限昇格も可能になり、重大な被害をもたらす恐れがあります。
攻撃者はその後、データの変更や削除、さらにはシステム設定の改変といった、特権的な操作を行う可能性があります。
セッショントークンの窃取を防ぐのは非常に難しい課題です。特に、開発者が利用する多様なエンドポイントが攻撃対象となるため、攻撃対象領域（アタックサーフェス）が広範に及ぶことが原因です。
こうしたすべてのエンドポイントを常に監視するのは、小規模・大規模を問わず、多くの企業にとって大きな負担となっています。
CDEと認証情報管理によるセッショントークン攻撃の大規模防止
CDE（クラウド開発環境）は、通常、DockerやPodmanコンテナで構築され、開発環境全体をコードとして定義する仕組みです。
開発者はこれをローカルPC上で使用することで、依存関係を隔離し、アプリケーションを容易に移植できるようになります。
近年では、MicrosoftやGoogleといったベンダーが、ローカルではなくクラウド上でアクセス可能なCDEを提供し始めており、これは効率的なDevOpsプロセスの実装に最適です。特に、リモートワークや分散チームを抱える企業にとって、オンラインCDEは非常に便利です。
CDEは、Microsoft Visual Studio CodeなどのクラウドIDEや、ターミナル、リモート接続対応のローカルIDEを通じて利用できます。
しかし、効率的なDevSecOpsの実現を目指す企業にとっては、私たちStrong Networkが開発したKubernetesベースのCDE管理プラットフォームが、さらに一歩進んだセキュリティを提供します。
このプラットフォームは、オンラインCDEにデータの外部流出を防止するセキュリティ機能を標準搭載しており、Gitリポジトリやネットワークサービスなどの開発リソースに対するシングルサインオン（SSO）機構を含みます。
オンラインアクセスの利便性と埋め込み型セキュリティを組み合わせることで、開発者がどこにいても、セキュアかつスケーラブルなDevSecOpsの運用が可能になります。
このようなセキュリティ機構を備えたCDEプラットフォームは、主要クラウドに対応しており、当社の製品が唯一の存在です。
開発者は、フィッシングやソーシャルエンジニアリングなどの標的になりやすいため、オンラインCDEの利用により、開発データをローカルPCから切り離すことが極めて重要です。
コードはコンテナ内に格納されるため、ローカルに感染したマルウェアからのアクセスを防ぐことができます。
ただし、セッショントークンの管理は別途対応が必要です。
以下に、当社のCDEが埋め込み型セキュリティを通じて、セッショントークン窃取への有効な対策となる理由をご紹介します。
トークンを開発者の手の届かない場所に保管する
まず、組織のリソースにアクセスするためのトークンは、開発者やそのローカル環境の手の届かない場所に置かれます。
DevOpsプロセスにおいては、開発者と各種ツールとの間の認証に多様な認証情報が使用されるため、トークンを保護するには多面的なアプローチが必要です。ここでは、Gitベースのコードリポジトリ管理ツールに焦点を当てます。
まず最初に、MFA（多要素認証）を含む資格情報ベースの認証の結果として発行されるセッショントークンを保護する必要があります。このトークンは、Azure ADやOktaといったアイデンティティプロバイダーを用いた委任認証によって、組織の管理下に置かれます。また、GitHubのようなWebアプリケーションへのアクセスは、リモートブラウザ分離とURLホワイトリストによって制御されます。
当社のプラットフォームでは、セキュリティ強化されたChromeブラウザを使用してユーザーをGitHubに認証し、ログイントークンはそのブラウザ環境内に隔離されます。仮にこのリモートブラウザが侵害されたとしても、ホワイトリストによって許可されたURLにしかアクセスできないため、感染のリスクは防がれます。
開発者がコードリポジトリアプリケーションに認証された後は、Gitプロトコルを使用してコードをpush・pullする際に使われる認証情報（SSHキーまたはOAuthトークン）を保護する必要があります。いずれの場合も、当社はプロキシメカニズムを利用し、これらの認証情報を開発者から隔離しています。このプロキシは、ユーザーのRBAC（役割ベースアクセス制御）モデルと、CDEに紐づく権限に基づいてアクセス制御を行います。
このような二重構造の仕組みによって、リポジトリの認証情報の漏洩を効果的に防止しており、その構成は下図でシンプルに説明されています。
次に、当社プラットフォームのWeb UIから発行されるログイントークンを保護する仕組みが必要です。
このプラットフォームは、開発者のワークスペース、セキュアブラウザアプリ、その他のツールへのアクセスを提供しているため、ログイントークンの管理は非常に重要です。
これが、「対策の第2段階」となります。
Strong NetworkのWebインターフェースへのアクセスを常時監視
私たちは、ダイナミック・クライアント・アテステーション（トークン使用端末の正当性を確認）を用いて、Strong NetworkのWeb UIへのアクセスを監視しています。
当社アプリケーションのトークン窃取を防ぐ1つの方法は、そのトークンを使用しているクライアントが、元々そのトークンをリクエストしたクライアントと同一であることを高い確度で確認することです。
これがいわゆるクライアントアテステーションと呼ばれるもので、クライアントから取得できる一連の「シグナル（情報）」を測定することで、バックエンドがリクエストの正当性を判断する仕組みです。
もちろん、非常に高度でリソースを持つ攻撃者であれば、正しいフットプリントを再現し、このアテステーションを回避できる可能性はあります。
しかしそれには、クライアント側の仕組みを完全に解析する必要があり（つまりフルアクセスが必要）、さらにアテステーションのペイロードを暗号化する鍵を抽出する必要があります（特にホワイトボックス暗号化が使われていれば非常に困難です）。
仮にそのような複雑な攻撃が成功し、攻撃者が盗まれたトークンを用いてプラットフォームにアクセスできたとしても、組織のリソースに対する認証情報には依然としてアクセスできません（詳細は下図参照）。
さらに、攻撃者が万が一プラットフォーム内に侵入した場合でも、当社のインサイダー脅威検知機構が、開発者による異常行動を検出します。
例えば、「コードベース全体をZIPに圧縮し、認識されていない外部サーバーへ送信する」といった行為は、即座に検知されます。
本記事が少しでも皆様のお役に立ち、参考になれば幸いです。
特に、オンラインのコード開発プラットフォームがCDE（クラウド開発環境）を提供することで、適切なセキュリティ機構とともに、組織のリソースを守る第一の防衛線となることをご理解いただけたかと思います。
