急激に進化する AI の脅威に対応する防御作とは

最近、Red Hat の Vincent Danen は、Mozilla と Anthropic のコラボレーションにおいて、AI モデルがたった 1 回の実行で Firefox の 271 件もの実際のセキュリティ上の不具合を検出したことを強調しました。AI が防御する側にそれができるのなら、攻撃する側に対しても同じことができるはずです。Danen は、「ソフトウェアに脆弱性がないことを前提にセキュリティ戦略を立てているのであれば、その時点ですでに敗北している」と述べています。 

コードの脆弱性は、単なる入り口にすぎません。実際の被害はその後から始まります。設定ミスのあるネットワークを通じた横方向の移動、権限が過剰な認証情報、更新されていないシークレット、また互いを無条件に信頼し合うサービスなどによる被害の影響が及びます。どのようなパッチサイクルも、そのスピードに追いつきません。これは、企業全体で「多層防御」をさらに強化する必要性を浮き彫りにしています。これは、セキュリティ侵害は避けられないものと前提とし、侵害そのものの影響を最小限に抑えることに重点を置くという、文化的な転換を意味します。 

これが、ゼロトラストの定義です。セキュリティ脆弱性のこの第 1 波の後には第 2 波、第 3 波が控えており、組織は「ゼロトラスト」を採用し、単なる予防から侵害の封じ込めへと移行する必要があります。つまり、ID、シークレット、ネットワークのセグメンテーション、ポリシーなど、あらゆるレイヤーにおいて最小権限の原則を徹底させる必要があります。組織には、こうした AI による脅威の拡散速度に合わせて実行される、自動化された対策が必要です。 Red Hat Ansible Automation Platform はこの取り組みを支援します。

AI による攻撃対象領域のシフト

従来の脆弱性スキャナーは、潜在的な問題にフラグを立て、担当者にトリアージを委ねます。AI によって、サイバー攻撃はありふれたものとなりました。今日の AI ツールは、本質的に 1 つのチーム全体が 1 つに凝縮されたようなもので、そのすべてがトークンだけで利用できます。SolarWinds のような壊滅的なセキュリティ侵害には、時間と深い専門知識、そして運が必要でしたが、現在では AI の登場により、意欲的な攻撃者は複雑なマルチプラットフォームの脆弱性を容易に連鎖させることができるようになっています。

一見すると小さな弱点であっても、積み重なれば防御する側にとって不利な状況を招きます。以下に例を示します。

• パスワードの再入力試行間隔が短すぎるログインページ
• 本人確認の再チェックを行わない設定ページ
• ログアウト時にセッショントークンを一時的に公開する API

これらは単独ではそれほど危険ではありません。個々に見れば、これらは「優先度低」としてバックログに留まるでしょうが、これらが連鎖すると、攻撃者がパスワードを総当たり攻撃で解読し、セッションが期限切れになる前に乗っ取り、管理者として設定ページにアクセスできてしまう可能性があります。些細なバグが 3 つあるだけで、システムへの侵入が可能になってしまいます。

これらの高度な AI モデルは、エクスプロイトコードを記述、コンパイル、実行し、失敗時の出力を活用して攻撃を反復的に改良し、再試行します。組織はこれを利用して、これまで知られていなかった脆弱性を迅速に発見し、修正していますが、不都合な真実として、この機能は攻撃者にも利用可能なのです。Danen が記したように、「防御する者がバグを見つけるのに役立つツールは、必然的に攻撃者がバグを見つけるのにも役立ってしまう」のです。攻撃者に必要なスキルのハードルは、一気に下がってしまいました。パッチ適用を迅速化することは解決策の一部ですが、それだけでは不十分であり、堅固な防御策で補完しなければなりません。  

防御には自動化された運用レイヤーが必要

Red Hat Enterprise Linux と SELinux および Red Hat OpenShift は、すでにプラットフォームレベルの強化機能を提供していますが、これらのプラットフォームレベルでの防御策だけでは不十分です。たとえば、SELinux は誰がアプリケーションをデプロイできるかを決定しません。セキュリティ情報イベント管理 (SIEM) システムが午前 3 時にブルートフォース攻撃を検知しても、コンテナの隔離機能だけではデータベースの認証情報を無効化することはできません。これらは、優れた防御戦略を構築する上で自動化が果たせる役割です。  

運用上の変更（デプロイ、パッチ適用、ネットワークの再構成、認証情報のローテーション）は、人、スクリプト、パイプライン、および自動化を通じて行われます。これらのパスがポリシーによって制御されていない場合は、プラットフォームの強化はある種の攻撃からは保護してくれる一方で、別の種類の攻撃に対しては完全に無防備な状態のままになってしまいます。 

NIST SP 800-207 はゼロトラスト・アーキテクチャ (ZTA) のブループリントを示しており、その中心となるのが Policy Enforcement Point (PEP; ポリシー適用ポイント) です。ほとんどの人は PEP を、ネットワークトラフィックをフィルタリングするファイアウォールやゲートウェイと見なしています。しかし、チームがアプリケーションのデプロイ、サーバーのパッチ適用、ネットワーク構成の変更などを行う際、これらのアクションはファイアウォールを通過するのではなく、自動化プロセスを通過します。結局のところ、ゼロトラストとは、自動化の大規模な展開を必要とする運用上の規律なのです。

Policy Enforcement Point (ポリシー適用ポイント) としての Ansible Automation Platform

Ansible Automation Platform が PEP として機能する場合、すべての運用アクションは、ID の確認、ポリシーの評価、シークレットの管理、および結果のログ記録を行うプラットフォームを経由します。これらは高度な機能ではなく、ゼロトラストが要求する最小限必要な制御です。オペレーターはターゲットシステムに直接アクセスすることはありません。Ansible Playbook がこれを行い、プラットフォームがオペレーターの権限を確認した後にのみ実行されます。

このアーキテクチャの利点は、一元的な適用と分散型の実行にあります。ポリシーの決定は単一のコントロールプレーンで行われますが、適用は自動化が実行されるあらゆる場所で行われます。サーバーへの直接接続やノートパソコンからのスクリプト実行がないため、「カウボーイエンジニアリング」や追跡不可能な設定のドリフトといったリスクを低減できます。これにより、認証情報のスプロール、シャドー自動化、管理外の横方向の移動といったアンチパターンにも対応できます。

このアーキテクチャは、脆弱なローカルエンドポイント上の高い権限の本番用の認証情報を排除することで、重大なセキュリティ脆弱性を軽減します。自動化プラットフォームが唯一の制御ポイントとなり、すべての変更には、識別情報、ポリシーの承認、および監査記録が伴います。 

Ansible Automation Platform は、デュアルリング方式の適用モデルを通じてこれを実装します。外部リングはプラットフォームレベルで動作します。ジョブテンプレートが起動する前に、Ansible Automation Platform は組み込みのポリシー適用機能を通じてOpen Policy Agent (OPA) サーバーに照会を行い、ジョブの完全なコンテキスト (誰が起動しているか、どのチームに所属しているか、どのテンプレートを実行しているか) を使用します。 

図 1：Ansible Automation Platform による外部リングと内部リングのポリシー適用

OPA はリクエストをポリシーに照らして評価し、許可または拒否を返します。外部リングによって拒否された場合、Playbook は実行されません。OPA ポリシーは、チームのメンバーシップを、許可されたテンプレートカテゴリーにマッピングします。

package aap.gateway
import rego.v1
default decision := {"allowed": true, "violations": []}
patching_teams := {"Infrastructure", "Security"}
network_teams := {"Infrastructure"}
app_teams := {"Applications", "DevOps"}
user_teams := {name | name := input.created_by.teams[_].name}
decision := {
    "allowed": false,
    "violations": [sprintf(
        "user '%s' is not in an authorised team for patching templates (requires: %v, has: %v)",
        [input.created_by.username, patching_teams, user_teams],
    )],
} if {
    not input.created_by.is_superuser
    is_patching_template
    not team_match(patching_teams)
}

図 2：Policy as Code チェックの Rego ポリシーの例

内部リングは、テンプレートまたはワークフロー自体の内部で動作します。VLAN の変更など、大きな影響を及ぼす可能性がある操作の場合、Playbook は SPIFFE ID (暗号処理ワークロードの ID) を取得して OPA に送信します。OPA は次の 3 つの条件を評価します。 

• ユーザーがチームメンバーシップを通じて認可されていること
• ワークロードが SPIFFE Verifiable Identity を通じて正当性が確認されていること
• リクエストされた変更が承認済みの範囲内にあること

これら 3 つすべてにパスする必要があります。

図 3：Ansible Automation Platform による複数ポリシー適用の例

これは、AIによる攻撃に対抗する上で重要です。エクスプロイトチェーンは脆弱性そのものではなく、適用ポイントで遮断されるからです。バグを連鎖させてサーバーへのアクセスを試みる AI エージェントは、データプレーンで足止めされます。そこでは、ネットワークのマイクロセグメンテーションや短期間の認証情報といったゼロトラストポリシーにより、外部アクセスや横方向の移動が遮断されるためです。このエージェントは、お客様の環境を悪用して悪意のあるアプリケーションを配布することも、Ansible Automation Platform を経由せずに企業ネットワークのポリシーを変更することもできません。ローカルでの侵害が検出されると、Ansible Automation Platform に含まれる Event-Driven Ansible が自動的にシステムを隔離し、セキュリティチームに即座に状況を通知します。

盗まれたユーザー認証情報は、ワークロードの ID が一致しないため、SPIFFE チェックに失敗します。侵害された自動化ノードは、攻撃者がユーザーの Ansible Automation Platform セッションを制御していないため、チームメンバーシップのチェックに失敗します。各リングはそれぞれ独立しています。いずれか 1 つを侵害するだけでは不十分です。これは、多層防御を実際に適用したものです。

動的な認証情報とマイクロセグメンテーションによる潜在的な影響の縮小　

自動化レイヤーでポリシーを適用しても、認証情報とネットワークパスは依然として攻撃対象となります。データベースのパスワードが毎月ローテーションされる場合、アクセス権を取得した攻撃者には 1 カ月の攻撃の機会が与えられます。アプリケーション層とデータベース層間でネットワークアクセス制御リスト (ACL) が永続的に開放されている場合、パスは常に利用可能な状態になります。

アプリケーションのデプロイワークフローが実行されると、Ansible Automation Platform は HashiCorp Vault から動的なデータベース認証情報を要求できます。これは、アプリケーションのスキーマにスコープが限定され、有効期限 (TTL) が 5 分間に設定された PostgreSQL ロールです。この認証情報は、デプロイメントの期間中のみ存在します。TTL の有効期限が切れると、ロールは削除されます。永続的なものは何もないため、盗まれるものもありません。

同じワークフロー内で、Ansible Automation Platform は、アプリケーションの IP アドレスからデータベースのポートへのトラフィックを許可する ACL エントリーを開くようネットワークを設定します。

AI によるエクスプロイトチェーンに対しては、これにより攻撃の様相が変わります。 ツールはバグを連鎖させてデータベース層に到達する可能性がありますが、4 分前に期限切れになった認証情報しか見つかりません。悪用可能な期間は、「誰かがパスワードを更新するまで」から「自動化が完了するまで」へと短縮されます。つまり、数カ月ではなく数分単位となります。また、アプリケーションを本番環境で実行している場合、Vault エージェントが継続的な認証情報のライフサイクルを処理します。

マシンの速度でのインシデント対応

AI エージェントがエクスプロイトを生成し、それらを連鎖させることができるのであれば、セキュリティ・オペレーション・センター (SOC) のアナリストが通知を受け、ログインしてアラートを確認し、調査を行い、手動で認証情報を無効にするといった対応は、デジタル脅威に対して人間のタイムラインで対応していることになります。

Event-Driven Ansible は、このギャップの解消を支援します。Splunk などの SIEM は、アプリケーションの認証エンドポイントに対してブルートフォースのパターンを検出します。Splunk はイベントストリーム経由で Event-Driven Ansible に対してアラートをトリガーでき、Event-Driven Ansible はイベントを評価して自動化ジョブを起動し、アクションを実行します。このジョブは HashiCorp Vault の API を呼び出して、アプリケーションが保持するすべてのアクティブな動的データベースリースを取り消します。アプリケーションは、即座にデータベースへの接続を失います。

—  
  name: Splunk Brute-Force credential revocation
  hosts: all
  sources:
    - ansible.eda.webhook:
        host: 0.0.0.0
        port: 5000
  rules:
    - name: Revoke credentials on SSH brute-force detection
      condition: event.payload.search_name is search("SSH Brute Force Detected")
      action:
        run_job_template:
          name: "Emergency: Revoke App Credentials"
          organization: Default

図 4：Splunk からのブルートフォースイベント用の Event-Driven Ansible ルールブックの例
 

検出から封じ込めまでのループは数秒で完了し、解決までの平均時間は数時間から数秒に短縮されます。潜在的な影響の規模は、「攻撃者がデータベースにアクセスできる可能性がある」の状態から、「データにアクセスできなくなったアプリケーションに攻撃者がアクセスできる」の状態へと縮小されます。

図 5：Event-Driven Ansible によるゼロトラスト・アーキテクチャの攻撃インシデント対応の例
 

これは自動化された封じ込めであり、その後に手動での復旧を行うことができます。Event-Driven Ansible は、資格情報の取り消しが安全なデフォルト設定であるため、人間の承認なしにこれを実行できます。アプリケーションはデータの提供を停止しますが、何も破壊されることはありません。復旧には、人間が調査を行い、脅威が解決されたことを確認した上で、アプリケーションを再デプロイする復旧ワークフローを起動する必要があります。復旧プロセスにこのチェックポイントが存在するのは、侵害発生後のアクセス権限の復旧を、人間の調査なしに自動化すべきではないためです。

多層防御、一つの防御

AI を活用した脆弱性の発見により、多層防御は不可欠なものとなっています。しかし、自動化された運用層を伴わない多層防御には、マシンの速度を活かした攻撃に見つけ出されてしまう隙が残ります。

3 つの層がこの隙間を埋め、それぞれが異なるポイントで AI によるエクスプロイトチェーンを断ち切ります。

• プラットフォームの強化 (コンパイラーフラグ、SELinux、コンテナの分離、Address Space Layout Randomization (ASLR)) により、最初のバグの悪用が難しくなります。AI モデルが脆弱性を発見する可能性はありますが、強化されたプラットフォームでは、コード実行に至るまでに多段階の攻撃チェーンを強いることになります。
• Ansible Automation Platform によるポリシー適用により、不正な操作経路を遮断します。エクスプロイトチェーンが成功したとしても、攻撃者は自動化コントロールプレーンを経由せずに、シークレットのデプロイ、パッチ適用、再構成、または機密情報へのアクセスを行うことはできません。盗まれた認証情報だけでは十分ではありません。
• Event-Driven Ansible による自動対応 は、横方向の移動が始まる前に侵害を封じ込めるのに役立ちます。検出から封じ込めまでを数秒で完了させるこのスピードは、AI 主導の攻撃の速度に匹敵するものであり、人間が関与する対応では到底及ばないものです。

各レイヤーは独立して機能します。プラットフォームの強化は、ポリシー適用に依存せず、ポリシー適用も、自動対応に依存しません。いずれか 1 つのレイヤーが機能しなくなっても、他の 2 つのレイヤーが被害を最小限に抑えます。この独立性により、セキュリティチームはアラートを追跡するのではなく戦略的なリスク軽減に時間を費やすことができます。また、ツールがポリシーよりも急速に進化した場合でも、ガードレールが確実に機能するという確信を持って、AI を活用した運用を導入できます。

ほとんどの組織が、プラットフォームの強化に取り組んでいます。多くの組織がゼロトラストの原則を採用しています。しかし、これらの脅威が要求するスピードで、ポリシーの適用と自動化を連携させている組織はほとんどありません。このギャップこそが、次なる侵害の標的となる場所です。上記の 3 つのレイヤーを組み合わせることで、AI 駆動型攻撃の影響に対する防御を強化することができます。  

関連資料

• Web セミナー： Red Hat Ansible Automation Platform によるゼロトラストの実装
• Web セミナー： セキュリティの自動化：ITOps の連携
• e ブック： セキュリティ自動化によるエンタープライズ IT の連携強化
• e ブック： Red Hat Ansible Automation Platform 初心者向けガイド
• インタラクティブ・チュートリアル セキュリティ自動化を含む IT 自動化
• Web ページ： セキュリティの自動化