マルチエージェント攻撃ツールはあらゆる手を尽くす

エグゼクティブサマリー

ARTEX や Cairn といったマルチエージェント型のオフェンシブセキュリティフレームワークは、標的組織への侵入経路を特定する任務を与えられると、あらゆる手を尽くして徹底的に調べ上げます（leave no stone unturned）。

ここ数か月間、Oktaでは、標的に対して受動的および能動的な偵察を実行するエージェントの爆発的な増加を観測しています。攻撃者がエージェントに対し、標的テナントのサインアップ、サインイン、アカウント復旧エンドポイントに対して既知のユーザー名のリストを総当たりで試行させ、ユーザーがどこでどのように認証を行っているかをエージェントに学習させている様子が確認されています。利用可能な場合、エージェントは不正な調査用アカウント（probe accounts）を登録し、これらの認証フローに潜在的な設定不備がないかテストします。エージェントは執拗であり、これらの一連の攻撃において調査されない（unprobed）フローは一つも残されません。

設定ミスは今やはるかに発見されやすくなっています。過剰なスコープが付与されたトークン、ワイルドカードが使われたコールバックURL、強度の低いグラントタイプ（grant types）、署名検証の欠如などを、エージェントは迅速に特定して悪用します。これらのマルチエージェントフレームワークは、脅威アクターがトークン費用を支払い続ける限り稼働し続けることが可能です。ワーカーエージェントがこれらのテストを390時間以上にわたって継続実行した攻撃事例も観測されています。

このような能動的な偵察の急増を受け、すべての組織はエージェントが発見・悪用する前にクライアントの設定ミスを特定し、修復することが求められます。これらを支援するために、後述の通り様々なツールが利用可能です。組織は、アイデンティティ管理に Okta を利用しているサードパーティアプリケーションと、機微な操作に使用されるファーストパーティクライアントアプリケーションの双方を監査する必要があります。Okta Workflows は、管理 API に対する特権操作を実行できる権限およびスコープを持つファーストパーティクライアントアプリケーションであるため、保護の優先順位が非常に高くなります。

Workflows：調査されないフローは一つもない

アイデンティティチームは、オンボーディング、オフボーディング、アクセス申請、通知の自動化や、HR、ITSM、セキュリティツールとの連携のために、Workflows、Auth0 Actions、サードパーティの代替ソリューションといったノーコード／ローコードツールへの依存度をますます高めています。これらの自動化処理は多くの場合、大きな特権を持って実行され、オプションとして HTTP リクエスト経由でアプリケーション境界の外部から呼び出すことも可能です。エージェントがあらゆる可能なフローを探索している現在の脅威環境を踏まえ、防御側は自動化処理が機微な情報の意図しない流出を招く可能性について考慮する必要があります。以下に、Workflows を強固に保護するための主要な検討事項を挙げます。

呼び出しURL（Invoke URLs）の厳格な保護

呼び出しURL（Invoke URL）は、Workflows 管理者が「API endpoint」カードを使用して外部クライアント経由でトリガー（「呼び出し」）できるフローを設定した際に生成されます。呼び出しURLは OAuth 2.0 またはクライアントシークレットを使用して保護できますが、管理者はオプションとしてセキュリティレベルに「None (public service)」（なし／パブリックサービス）を選択することも可能です。これが選択されると、呼び出しURLにアクセスできる人物であれば誰でも、認証されていない状態であってもフローを実行し、その出力を閲覧することができてしまいます。Okta は Workflows コンソールにおいて、このオプションのリスクについて次のような警告を表示しています。

「このフローは、URLにアクセスできるあらゆる人物またはサービスによって実行可能です。本番環境のフローには別のセキュリティオプションを使用することを推奨します。」

この警告が表示される理由は、呼び出しURLが外部クライアントからトリガーされるよう設計されているためです。フローのセキュリティは、それを利用するように構成されたクライアントの保護と、そのURLへのアクセス方法の保護の両方に依存します。たとえば、呼び出しURLがチケットやチャット上で共有されたり、クリップボードにコピーされたり、ブラウザの履歴やクライアントアプリケーションのログに記録されたりする可能性があります。

認証を要求しない、パブリックに露出した呼び出しURLにアクセスした攻撃者は、それを利用してフローを呼び出す（「実行する」）ことができます。一部のユースケースでは、フローの呼び出し自体はリスクをもたらさない場合もあります。OAuth 2.0 もクライアントシークレットもサポートしていないツールの Webhook など、リクエストの送信はできても認証が行えないシステムが存在し、パブリックな呼び出しURLがフローへ到達する唯一の手段である場合などです。公開登録フォームも一例であり、アカウントを持たない人を含む誰もが送信できなければならないためです。機微でない読み取り専用のデータのみを返し、意味のある権限を持つコネクションを使用していないフローも、パブリックであってもリスクはほとんどありません。フローの呼び出しが危険になるのは、それがアイデンティティデータを変更する場合や、クライアント出力に機微なデータを返す場合です。したがって管理者は、パブリックな呼び出しURLを持つ各フローが何にアクセスできるのかを注意深く確認する必要があります。

管理者には以下の対応を推奨します。

• アイデンティティデータにアクセスする、または特権アクションを実行するすべてのフローに対して「Secure with OAuth 2.0」を選択すること。

• 「None (public service)」は、十分にレビューされ、機微なデータへのアクセスや特権アクションが存在しないことが確認されたフローのみに限定すること。

URLからクライアントトークンを排除する

クライアントトークン（Client Secret 等）をクエリパラメータなどとして URL 自体に含める設定は避けてください。URL は Web サーバーのアクセスログ、プロキシログ、ブラウザ履歴、通信経路上に平文で記録・キャッシュされやすく、漏洩のリスクが跳ね上がります。認証情報は常に HTTP ヘッダー（Authorization ヘッダー等）などのセキュアな伝送経路を介して渡す構成にしてください。

コンソールアクセスに最小権限の原則を適用する

Workflows 管理コンソールへのアクセス権は、必要不可欠な担当者のみに限定して付与してください。不要な特権を持つアカウントが存在すると、アカウント侵害が発生した際の影響範囲が広範囲に及びます。ロールベースアクセス制御（RBAC）を徹底し、管理権限を最小限に絞り込みます。