セキュリティー自動化の実装


Red Hat Ansible Automation Platform 2.6

Ansible を使用してセキュリティーイベントを識別および管理する

Red Hat Customer Content Services

概要

このガイドでは、Ansible を使用してセキュリティーイベントを特定、トリアージ、および対応するために必要なさまざまなセキュリティープロセスを自動化および合理化する手順を説明します。

Red Hat ドキュメントへのフィードバック (英語のみ)

このドキュメントの改善に関するご意見がある場合や、エラーを発見した場合は、https://access.redhat.com から Technical Support チームに連絡してください。

第1章 Ansible セキュリティー自動化によるファイアウォールポリシー管理

セキュリティーオペレーターは、Ansible セキュリティー自動化を使用して複数のファイアウォールポリシーを管理したり、送信元 IP アドレスが宛先 IP アドレスにアクセスするのをブロックまたはブロック解除するファイアウォールルールを作成および削除したりできます。

1.1. ファイアウォールポリシー管理について

組織のネットワークファイアウォールは、攻撃に対する防害となる最初の行と、セキュアな環境を維持するための重要なコンポーネントです。セキュリティーオペレーターは、セキュアなネットワークを構築し、管理して、ファイアウォールが組織のファイアウォールポリシーで定義した受信および送信ネットワークトラフィックのみを許可するようにします。ファイアウォールポリシーは、ネットワークを有害な受信トラフィックおよび送信トラフィックに対して保護するセキュリティールールで構成されます。

さまざまな製品やベンダー全体で複数のファイアウォールルールを管理することは、セキュリティーチームにとって困難であり、時間がかかる可能性があります。複雑なタスクに関連する手動のワークフロープロセスにより、エラーが発生し、最終的にはアプリケーションの疑わしい動作を調査したり、サーバー上の継続的な攻撃を中止したりすることが可能になります。セキュリティーポートフォリオのすべてのソリューションが同じ言語で自動化されると、セキュリティーアナリストとオペレーターの両方が、さまざまな製品に対して一連のアクションを短時間で実行できます。この自動化プロセスは、セキュリティーチームの全体的な効率を最大化します。

Ansible のセキュリティー自動化は、さまざまなベンダーのさまざまなセキュリティーテクノロジーと相互作用します。Ansible を使用すると、セキュリティーチームは、デプロイメントを正常に実行するための統一された方法で異なる製品、インターフェイス、およびワークフローを管理できます。たとえば、セキュリティーチームは、エンタープライズファイアウォールなどのサポートされているテクノロジーで IP と URL のブロックとブロック解除などのタスクを自動化できます。

1.2. ファイアウォールルールの自動化

Ansible セキュリティー自動化により、さまざまな製品全体で一連のアクションを必要とするさまざまなファイアウォールポリシーを自動化できます。acl_manager ロールなどの Ansible ロールを使用して、IP または URL のブロックやブロック解除などの多くのファイアウォールデバイスについて アクセス制御リスト (ACL) を管理できます。ロールを使用すると、既知のファイル構造に基づいて、関連する変数、ファイル、タスク、ハンドラー、およびその他の Ansible アーティファクトを自動的に読み込みます。ロールでコンテンツを分類した後に、簡単に再利用し、他のユーザーと共有できます。

以下のラボ環境は、実際のエンタープライズセキュリティーアーキテクチャーの簡素化された例です。ここでは、複雑で、追加のベンダー固有のツールが含まれます。これは、侵入アラートを受信し、攻撃者の IP アドレスをブロックする acl_manger ロールを使用して Playbook をすぐに実行する典型的なインシデント対応シナリオです。

チーム全体で Ansible セキュリティー自動化を使用して、調査、脅威ハンティング、インシデント対応をすべて 1 つのプラットフォームで行うことができます。Red Hat Ansible Automation Platform は、セキュリティーチーム内で使用および再利用を容易にする認定コンテンツコレクションを提供します。

1.2.1. 新しいファイアウォールルールの作成

acl_manager ロールを使用して、宛先 IP アドレスへのアクセスからソース IP アドレスをブロックする新しいファイアウォールルールを作成します。

前提条件

  • 最新バージョンの ansible-core がインストールされている。
  • 新規ポリシーを適用する Check Point Management サーバーへのアクセスがある。

手順

  1. ansible-galaxy コマンドを使用して acl_manager ロールをインストールします。

    $ ansible-galaxy install ansible_security.acl_manager

  2. 新しい Playbook を作成し、以下のパラメーターを設定します。たとえば、送信元オブジェクト、宛先オブジェクト、2 つのオブジェクト間のアクセスルール、および管理している実際のファイアウォール (Check Point など) です。

    - name: block IP address
      hosts: checkpoint
      connection: httpapi
    
      tasks:
        - include_role:
            name: acl_manager
            tasks_from: block_ip
          vars:
            source_ip: 172.17.13.98
            destination_ip: 192.168.0.10
            ansible_network_os: checkpoint
    Copy to Clipboard Toggle word wrap
  3. Playbook を実行します ($ ansible-navigator run --ee false <playbook.yml>)。

検証

宛先 IP アドレスへのアクセスからソース IP アドレスをブロックする新しいファイアウォールルールを作成しました。MGMT サーバーにアクセスし、新しいセキュリティーポリシーが作成されていることを確認します。

1.2.2. ファイアウォールルールの削除

acl_manager ロールを使用してセキュリティールールを削除します。

前提条件

  • Ansible 2.9 以降がインストールされている。
  • 新しいポリシーを適用するファイアウォール MGMT サーバーへのアクセスがある。

手順

  1. ansible-galaxy コマンドを使用して acl_manager ロールをインストールします。

    $ ansible-galaxy install ansible_security.acl_manager

  2. CLI を使用して、acl_manger ロールで新規 Playbook を作成し、パラメーター (例: ソースオブジェクト、宛先オブジェクト、2 つのオブジェクト間のアクセスルール) を設定します。

    - name: delete block list entry
      hosts: checkpoint
      connection: httpapi
    
        - include_role:
            name: acl_manager
            Tasks_from: unblock_ip
          vars:
            source_ip: 192.168.0.10
            destination_ip: 192.168.0.11
            ansible_network_os: checkpoint
    Copy to Clipboard Toggle word wrap
  3. Playbook $ ansible-navigator run --ee false <playbook.yml> を実行します。

検証

ファイアウォールルールが削除されました。MGMT サーバーにアクセスし、新しいセキュリティーポリシーが削除されていることを確認します。

第2章 Ansible Automation Platform によるネットワーク侵入検知/防止システム (IDPS) の自動化

Ansible Automation Platform を使用して、侵入検知/防止システム (IDPS) を自動化できます。このガイドの目的上、Snort を IDPS として使用します。Automation Hub を使用して、タスク、ロール、モジュールなどのコンテンツコレクションを消費し、自動化されたワークフローを作成します。

2.1. 要件および前提条件

Ansible Automation Platform を使用して IDPS の自動化を開始する前に、IDPS を正常に管理するために必要な適切なインストールと設定があることを確認してください。

  • Ansible-core 2.15 以降がインストールされている。
  • SSH 接続およびキーが設定されている。
  • IDPS ソフトウェア (Snort) がインストールされ、設定されている。
  • 新しいポリシーを適用する IDPS サーバー (Snort) にアクセスできる。

2.1.1. IDPS インストールの検証

Snort が正常に設定されたことを確認するには、次の手順に従います。

手順

  1. sudo を使用して snort を呼び出し、バージョンを尋ねます。

      $ sudo snort --version
    
       ,,_     -*> Snort! <*-
      o"  )~   Version 2.9.13 GRE (Build 15013)
      ""    By Martin Roesch & The Snort Team: http://www.snort.org/contact#team
            Copyright (C) 2014-2019 Cisco and/or its affiliates. All rights reserved.
            Copyright (C) 1998-2013 Sourcefire, Inc., et al.
            Using libpcap version 1.5.3
            Using PCRE version: 8.32 2012-11-30
            Using ZLIB version: 1.2.7
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを使用して、サービスがアクティブに実行されていることを確認します。

    sudo systemctl:

    $ sudo systemctl status snort
    ● snort.service - Snort service
       Loaded: loaded (/etc/systemd/system/snort.service; enabled; vendor preset: disabled)
       Active: active (running) since Mon 2019-08-26 17:06:10 UTC; 1s ago
      Main PID: 17217 (snort)
       CGroup: /system.slice/snort.service
               └─17217 /usr/sbin/snort -u root -g root -c /etc/snort/snort.conf -i eth0 -p -R 1 --pid-path=/var/run/snort --no-interface-pidfile --nolock-pidfile
    [...]
    Copy to Clipboard Toggle word wrap
  3. Snort サービスの実行がアクティブでない場合は、systemctl restart snort で再起動し、ステータスを再度確認します。
  4. サービスがアクティブに実行されていることを確認したら、CTRLD を同時に押すか、コマンドラインで exit と入力して Snort サーバーを終了します。以降のすべてのやり取りは、Ansible コントロールホストから Ansible Automation Platform を通じて実行されます。

2.2. Ansible Automation Platform での IDPS ルールの自動化

IDPS を自動化するには、ids_rule ロールを使用して Snort ルールを作成および変更します。Snort はルールベースの言語を使用しており、ネットワークトラフィックを分析して指定のルールセットと比較します。

以下のラボ環境では、Ansible セキュリティー自動化の統合に関するデモを紹介します。“Attacker” と呼ばれるマシンは、IDPS が実行されているターゲットマシン上で、攻撃パターンを想定してシミュレートします。

実際の設定では、他のベンダーやテクノロジーが含まれている点に注意してください。

2.2.1. 新しい IDPS ルールの作成

ids_rule ロールを使用して IDPS のルールおよび署名を管理します。たとえば、新しいルールを設定して、ファイアウォールで以前の攻撃に合わせた特定のパターンを検索できます。

注記

現在、ids_rule ロールは Snort IDPS のみをサポートしています。

前提条件

  • Snort サーバーに変更を加えるには、root 権限が必要です。

手順

  1. ansible-galaxy コマンドを使用して ids_rule ロールをインストールします。

    $ ansible-galaxy install ansible_security.ids_rule

  2. add_snort_rule.yml という名前の新しい Playbook ファイルを作成します。以下のパラメーターを設定します。

    - name: Add Snort rule
      hosts: snort
    Copy to Clipboard Toggle word wrap
  3. become フラグを追加して、Ansible が権限昇格を処理するようにします。

    - name: Add Snort rule
      hosts: snort
      become: true
    Copy to Clipboard Toggle word wrap
  4. 以下の変数を追加して IDPS プロバイダーの名前を指定します。

    - name: Add Snort rule
      hosts: snort
      become: true
    
      vars:
        ids_provider: snort
    Copy to Clipboard Toggle word wrap
  5. 次のタスクとタスク固有の変数 (ルール、Snort ルールファイル、ルールの状態 (存在または不在) など) を Playbook に追加します。

    - name: Add Snort rule
      hosts: snort
      become: true
    
      vars:
        ids_provider: snort
    
      tasks:
        -  name: Add snort password attack rule
           include_role:
             name: "ansible_security.ids_rule"
           vars:
             ids_rule: 'alert tcp any any -> any any (msg:"Attempted /etc/passwd Attack"; uricontent:"/etc/passwd"; classtype:attempted-user; sid:99000004; priority:1; rev:1;)'
             ids_rules_file: '/etc/snort/rules/local.rules'
             ids_rule_state: present
    Copy to Clipboard Toggle word wrap

    タスクは、ターゲットマシンに変更を加えるコンポーネントです。このようなタスクを定義するロールを使用しているため、必要となるエントリーは include_role のみです。

    ids_rules_file 変数は local.rules ファイルに定義された場所を指定し、ids_rule_state 変数は、ルールが存在しない場合には作成する必要があることを示しています。

  6. 以下のコマンドを実行して Playbook を実行します。

    $ ansible-navigator run add_snort_rule.ym --mode stdout

    Playbook が実行されると、新しく作成されたルールに加えて、すべてのタスクが実行されます。Playbook の出力により、PLAY、TASK、RUNNING HANDLER、および PLAY RECAP が確認されます。

検証

IDPS ルールが正常に作成されたことを確認するには、Snort サーバーに対して SSH を実行し、/etc/snort/rules/local.rules ファイルの内容を表示します。

第3章 Ansible Automation Platform のセキュリティー自動化のユースケース

Ansible Automation Platform は、強力な IT セキュリティー体制の維持に必要な多くの手動タスクを自動化する機会を組織に提供します。セキュリティー操作を自動化できる領域には、セキュリティーイベントの対応と修復、日常的なセキュリティーオペレーション、セキュリティーポリシーと規制の遵守、IT インフラストラクチャーのセキュリティー強化などがあります。

3.1. Security Operations Center の一部としての Red Hat Ansible Automation Platform

組織を保護することは重要なタスクです。Security Operations Center (SOC) の機能を自動化すると、セキュリティーオペレーション、対応、および修復作業を大規模に効率化し、侵害のリスクとコストを削減できます。Red Hat Ansible Automation Platform は、セキュリティーチーム、ツール、プロセスを接続して、自動化の導入と使用を効率化できます。ここでは、自動化によってビジネスを保護し、増大するセキュリティーの脅威に迅速に対応する方法を説明します。

セキュリティーオペレーションセンターの簡素化 では、次のようなユースケースを含む SOC 運用を自動化する利点の概要を示します。

  • 調査の強化
  • 脅威ハンティング
  • インシデント対応

3.2. Ansible Automation Platform によるパッチ適用の自動化

ソフトウェアのパッチ適用は、あらゆる場所のセキュリティーおよび IT 運用チームにとって基本的な活動です。パッチを最新の状態に保つことは、ソフトウェアの脆弱性を修正し、コンプライアンス要件を満たすうえで重要です。しかし、大規模なシステムに手動でパッチを適用すると、時間がかかり、ミスが発生しやすくなります。組織は、セキュリティー、コンプライアンス、ビジネス目標を満たすパッチ管理戦略を検討し、企業全体で利用可能な IT 資産に対して適用するパッチの種類 (既知のエクスプロイト、重大な脆弱性、最適化、定期的な更新、新機能など) の優先順位を付ける必要があります。ポリシーと優先順位を定義し、パッチ適用計画を確立したら、Red Hat Ansible Automation Platform を使用してパッチ管理に関連する手動タスクを自動化し、パッチのデプロイの速度と精度を向上させ、ヒューマンエラを減らし、ダウンタイムを抑えることができます。

3.2.1. パッチ適用の自動化の利点

パッチ適用プロセスを自動化すると、次のような多くの利点が得られます。

  • ミスが発生しやすい手作業が削減されます。
  • 大規模にパッチをデプロイする時間が短縮されます。
  • 類似するシステム間でパッチの一貫性が確保されます。類似するシステムに手動でパッチを適用すると、ヒューマンエラー (1 つまたは複数のパッチの適用を忘れる、異なるバージョンを使用してパッチを適用する) が発生し、一貫性に影響が出る可能性があります。
  • 更新時にパッチを適用する前にシステムのスナップショットを取得する必要がある場合や、パッチを適用するときに追加の設定変更が必要な場合に、複雑なパッチ適用シナリオのオーケストレーションが可能です。

3.2.2. パッチ適用の例

以下の Playbook は、パッチ適用の例として示しています。実稼働環境で使用する前に、ターゲット環境に合わせて変更し、十分にテストしてください。以下の例では、RHEL および dnf パッケージマネージャーを使用するその他のオペレーティングシステム上のパッケージを管理するために ansible.builtin.dnf モジュールを使用します。他の Linux オペレーティングシステム、Microsoft Windows、およびさまざまなネットワークデバイスにパッチを適用するためのモジュールも利用できます。

3.2.2.1. すべてを最新の状態に保つ

ラボやその他の非実稼働システムなど、一部の Red Hat Enterprise Linux サーバーでは、利用可能なすべてのパッチを定期的にインストールする必要がある場合があります。次の Playbook の例は、毎週実行するようにスケジュールされ、最新の RPM すべてを使用してシステムを更新するジョブテンプレートで使用できます。

- name: Install all available RPM updates
  hosts: target_hosts
  become: true

  tasks:
    - name: Install latest RPMs
      ansible.builtin.dnf:
        name: '*'
        state: latest
Copy to Clipboard Toggle word wrap

id="ref-install-security-updates"]

3.2.2.2. セキュリティー更新のみをインストールする

セキュリティーエラータを含むすべての RPM を最新の状態に保つことを要求するポリシーを採用している組織では、定期的に実行されるジョブテンプレートで次の Playbook を使用できます。

- name: Install all security-related RPM updates
  hosts: target_hosts
  become: true

  tasks:
    - name: Install latest RPMs with security errata
      ansible.builtin.dnf:
        name: '*'
        security: true
        state: latest
Copy to Clipboard Toggle word wrap
3.2.2.3. パッケージバージョンを指定する

実稼働システムには、確立された設定管理プラクティスとして、システムを正しく設定して期待どおりに動作させるために、テスト済みの既知のソフトウェアの組み合わせだけをデプロイするというプラクティスがあります。これには、システムの更新によって運用アプリケーションに問題が発生しないように、既知のバージョンのオペレーティングシステムソフトウェアとパッチのみをデプロイすることも含まれます。

注記

次のサンプル Playbook では、ターゲットホストが RHEL 9 オペレーティングシステムを使用する場合に、特定のバージョンの httpd RPM とその依存関係をインストールします。指定したバージョンがすでに存在している場合、または別のバージョンの RHEL がインストールされている場合、この Playbook はアクションを実行しません。

- name: Install specific RPM versions
  hosts: target_hosts
  gather_facts: true
  become: true

  vars:
    httpd_packages_rhel9:
      - httpd-2.4.53-11.el9_2.5
      - httpd-core-2.4.53-11.el9_2.5
      - httpd-filesystem-2.4.53-11.el9_2.5
      - httpd-tools-2.4.53-11.el9_2.5
      - mod_http2-1.15.19-4.el9_2.4
      - mod_lua-2.4.53-11.el9_2.5

  tasks:
    - name: Install httpd and dependencies
      ansible.builtin.dnf:
        name: '{{ httpd_packages_rhel9 }}'
        state: present
        allow_downgrade: true
    when:
      - ansible_distribution == "RedHat"
      - ansible_distribution_major_version == "9"
Copy to Clipboard Toggle word wrap
注記

allow_downgrade: true を設定すると、定義されたパッケージの新しいバージョンがシステムにインストールされている場合、代わりに指定したバージョンにダウングレードされます。

id="ref-complex-patching-scenarios"]

3.2.3. 複雑なパッチ適用シナリオ

Ansible Automation Platform では、複数の自動化ジョブをワークフローに連結することができます。ワークフローは、複雑なパッチ適用シナリオで複数のステップを調整するために使用できます。

次の複雑なパッチ適用シナリオの例では、仮想マシンのスナップショットを取得し、仮想マシンにパッチを適用し、ワークフローでエラーが発生したときにチケットを作成する方法を示します。

  1. プロジェクトの同期を実行して、最新の Playbook が利用可能であることを確認します。並行して、インベントリー同期を実行し、ターゲットホストの最新リストが利用可能であることを確認します。
  2. 各ターゲットホストのスナップショットを取得します。

    1. スナップショットタスクが失敗した場合は、関連情報を記載したチケットを送信します。
  3. 各ターゲットホストにパッチを適用します。

    1. パッチ適用タスクが失敗した場合は、スナップショットを復元し、関連情報を記載したチケットを送信します。
  4. パッチ適用タスクが成功した各スナップショットを削除します。

次のワークフロー図は、複雑なパッチ適用シナリオの例のコンポーネントがどのように実行されるかを示しています。

Workflow representation

第4章 セキュリティー関連のイベントに対応するための Event-Driven Ansible

Ansible セキュリティー自動化により、複数のセキュリティーテクノロジーの統合が可能になります。この統合は、さまざまな製品、インターフェイス、ワークフローを統合し、セキュリティー組織内のさまざまなチームプロセスを調整する必要があるため、技術的に複雑で困難です。Event-Driven Ansible は、これらの課題を解決します。

4.1. セキュリティーのための Event-Driven Ansible の使用

Event-Driven Ansible は、組織がリアルタイムのイベントに動的に対応できるようにする強力な自動化フレームワークです。さまざまなソースからのトリガーをリッスンし、条件を評価して、Ansible Playbooks を使用して自動対応を実行します。

セキュリティーオペレーションの観点では、Event-Driven Ansible はセキュリティー関連のイベントへの対応を自動化することで、迅速なインシデント対応、脅威の軽減、システム強化を実現します。イベント駆動型の自動化は、IT 環境内の変化する状況に自動的に応答し、問題をより迅速に解決して、日常的な反復タスクを削減するプロセスです。Event-Driven Ansible は、ルールを使用してイベントのソースと対応するアクションを結びつけます。意思決定機能は、監視ツールから「イベント」を受信し、必要なアクションをトリガーします。Ansible ルールブックはイベントのソースを定義し、「もしこうなったら、こうする (if-this-then-that)」という形式の指示を使用して、そのイベントに遭遇した際に実行するアクションを記述します。Ansible ルールブックは、Playbook の実行やモジュールの直接実行などのアクションにイベント条件をマッピングします。Ansible を通じて、このイベント駆動型の自動化プロセスがセキュリティー関連のイベントに適用され、イベント駆動型セキュリティーが実現します。セキュリティーリスクを迅速に特定して対処するには、広範な監視ツールのセットが必要です。これらのツールが問題や懸念事項を特定すると、イベント駆動型の自動化ソリューションがログソースを Security Information and Event Management (SIEM) システムに返し、人間による介入、トリアージ、または解決が行われます。自動化されたイベント駆動型の脅威対応の例には、ポート、IP、またはデバイスのシャットダウンが含まれます。イベントソースがネットワークルーターを監視していて、ルーターが応答していないことを検出すると、これをイベントとして認識します。Event-Driven Ansible はこのイベントを受け取り、ルールブックのルールで定義された条件と照合します。この場合の条件は、「‘no response’ を示すイベントに遭遇した場合、ルーターをリセットする」となります。Event-Driven Ansible はルールブック内の指示をトリガーし、ルーターがリセットされ、正常な機能に復旧します。これは人間の介入なしにいつでも発生する可能性があります。

Event-Driven Ansible は、次の一般的なセキュリティーユースケースを自動化できます。

  • エンタープライズファイアウォール
  • 侵入検知/防止システム (IDPS)
  • セキュリティー情報イベント管理 (SIEM) システム
  • 特権アクセス管理 (PAM) ツール
  • エンドポイント保護プラットフォーム (EPP)
  • 脅威の検出と対応
  • 自動化されたインシデント対応
  • ゼロトラストネットワークアクセス (ZTNA)
  • コンプライアンスと強化
  • フィッシング対策

以下は、不正な SSH アクセスを検出して対応するために Event-Driven Ansible を使用するワークフローシナリオの例です。

  1. イベントソース: セキュリティー監視ツールが、複数の失敗した SSH ログイン試行を検出します。
  2. トリガー: イベントが Event-Driven Ansible に送信されます。
  3. Event-Driven Ansible ルールブックの評価: 失敗したログイン回数がしきい値を超えると、Ansible Playbook を実行します。

    • 自動化された対応アクション:
    • ファイアウォールで送信元 IP をブロックします。
    • セキュリティーチームに通知を送信します。
    • フォレンジック分析用にログを収集します。

4.2. F5 のケーススタディ

イベント駆動型の自動化により、疑わしいアクティビティーに即座に対応できます。Event-Driven Ansible の汎用性は、F5 Application Delivery and Security Platform によって実証されています。Elasticsearch や Kibana などのイベント監視ツールによって F5 Application Delivery and Security Platform 内で異常または悪意のあるアクティビティーが検出されると、Event-Driven Ansible のルールブックが即座に応答し、F5 Advanced WAF および BIG-IP Application Security Manager といった F5 ソリューションを使用して潜在的な攻撃を阻止します。

このエージェントレス自動化システムは、API や Webhook などの既存のトランスポートメカニズムを使用して、相互運用性を容易にします。Event-Driven Ansible 向けの F5 コンテンツコレクションは、信頼性の高い自動化とサポートを確保するために F5 によって開発され、Red Hat によって認定されています。F5 と Red Hat は連携して、組織がリスクを軽減し、平均解決時間を短縮し、最終的には限られたリソースを解放して価値の高いタスクに集中できるよう支援します。

4.2.1. セキュリティーオペレーションのユースケース

F5 と Event-Driven Ansible による自動化は、以下のようなセキュリティーオペレーションのユースケースで役立ちます。

4.2.2. 強化されたセキュリティー調査

サイバー攻撃は組織にとって永続的な脅威であり、セキュリティーツールは、人員不足のセキュリティーチームが調査できる以上のアラートを生成します。組織は、自動化を通じてセキュリティーチームが問題をより効率的に特定および修復できるようにすることで、大幅なコスト削減を実現できます。セキュリティー自動化の一般的な最初のステップは、事前に定義された調査 Playbook に従って、潜在的なセキュリティーインシデントの調査フェーズを迅速化することです。新しいセキュリティーイベントによって Ansible ルールブックがトリガーされると、自動化されたワークフローが複数の F5 ソリューションからデータを収集して相関させ、セキュリティーアナリストが調査に費やす時間を大幅に短縮します。その結果、インシデントを特定して封じ込めるまでの平均時間が短縮されます。

4.2.3. 改善された脅威ハンティング

企業は多数のエンドポイントデバイスを管理しています。この攻撃対象領域により、組織は複数の脅威ベクトルにさらされることになります。多くのセキュリティーチームには、プロアクティブな脅威ハンティングに投資するリソースが不足していますが、自動化を使用して脅威データを監視および相関させ、実用的な分析情報を生成することで、セキュリティーチームはセキュリティーの問題をより効果的に防止し、脅威の露出を迅速に検出できます。

4.2.4. セキュリティーインシデントへの対応の迅速化

自動化されたサイバー攻撃の状況では、脅威に対する即時の対応が不可欠です。セキュリティーチームは、事前に構築された検証済みのワークフローを実行する自動化を使用して、即座に対応し、セキュリティーインシデントを抑制または防止できるため、攻撃者の滞在時間と被害を軽減できます。ルールは、特定のイベントに基づいてどのワークフローをトリガーするかを決定します。イベントが検出されると、自動化が実行されて問題が修復され、攻撃者のアクセスが防止され、エンドポイントが隔離され、セキュリティーポリシーが更新されて将来の発生が防止されます。たとえば、悪意のあるユーザーがアプリケーションにアクセスしようとしていることが検出された場合、イベント監視によって Ansible ルールブックがトリガーされ、悪意のあるユーザーをブロックしつつ、正当なユーザーによるアプリケーションアクセスを引き続き許可するよう F5 Advanced WAF に指示できます。

4.3. F5 と Event-Driven Ansible を使用した例

F5 と Event-Driven Ansible を使用したサンプルコードは GitHub で入手できます。このコードは、フィルター内で一致を見つけたウォッチャーの各インスタンスを記録し、そのコードからソース IP を CSV リストにコピーします。次に、リストはコードを実行するためのメッセージとともに、Webhook 内の変数として送信されます。

この高レベルのワークフローは、次の図とコードワークフローの例で説明されています。

+ F5 and Ansible workflow

ワークフローの手順は次のとおりです。

  1. F5 BIG-IP は監視ログを Elastic にプッシュします。
  2. Elastic は、そのフィルターと基準が設定されたウォッチャーを使用しながら、データを取り込み、保存します。
  3. ウォッチャーは、その基準に一致するイベントを検出し、ペイロード付きの Webhook を Event-Driven Ansible に送信します。
  4. Event-Driven Ansible のルールブックは、Ansible Automation Platform 内のジョブテンプレートをトリガーするイベントからトリガーされ、Elastic によって提供されるペイロードを送信します。
  5. Ansible Automation Platform のテンプレートは、Event-Driven Ansible (元々は Elastic によって提供) によって提供されるペイロードを使用して、F5 BIG-IP を保護するための Playbook を実行します。

4.3.1. ロギングイベントからの応答の駆動

Ansible 検証済みコンテンツは、事前にテストおよび検証された、信頼できる Ansible ロールと Playbook のコレクションです。このコンテンツは、デプロイメント全体にわたってインフラストラクチャーを管理するためのセキュアで信頼性が高く一貫性のある方法を容易に提供できるように設計されています。検証済みのコンテンツはそのまま使用できるため、カスタム Ansible コンテンツの作成に必要な時間と労力が削減されます。次のユースケースは、ログイベントに対する Event-Driven Ansible の応答の例を示しています。

4.3.2. ユースケース: AWS CloudTrail

AWS CloudTrail は、他の AWS サービスによって行われた API 呼び出しを含む、AWS アカウントで行われたすべての API 呼び出しをログに記録するサービスです。デフォルトでは、CloudTrail ログは暗号化されていない形式で S3 バケットに保存されます。CloudTrail ログがセキュアであることを確認するには、AWS KMS を使用して CloudTrail ログの暗号化を有効にします。CloudTrail ログが保存される S3 バケットを暗号化するために使用される KMS キーを作成して、CloudTrail ログの暗号化を有効にします。次に、このキーを使用してログを暗号化するように CloudTrail を設定します。

暗号化を有効にすると、すべての CloudTrail ログは、S3 バケットに書き込まれる際に自動的に暗号化されます。ログは、指定した KMS キーを使用してのみ復号化できます。これにより、ログがセキュアあり、許可されたユーザーとサービスのみがアクセスできることが確立されます。

AWS CloudTrail ログの暗号化は、いくつかの理由で重要です。

  • 機密情報の保護: CloudTrail ログには、API 呼び出し、ユーザーアイデンティティー、リソース情報など、AWS アカウントに関する豊富な情報が含まれています。CloudTrail ログを暗号化すると、この機密情報を不正アクセスや改ざんから保護できます。
  • コンプライアンス要件: HIPAA や PCI DSS などの多くのコンプライアンス標準では、機密情報を保護するためにログの暗号化が必要です。CloudTrail ログを暗号化すると、これらの標準に準拠できるようになります。
  • 改ざんの防止: CloudTrail のログ暗号化は、ログの改ざんを防ぐのに役立ちます。これにより、ログの整合性が維持され、AWS アカウントへのすべての API 呼び出しの正確な記録が維持されます。
  • データの保護: CloudTrail ログの暗号化は、データに追加のセキュリティー層を提供します。S3 バケットが侵害された場合でも、暗号化キーがなければ、暗号化されたログにアクセスすることはできません。

Event-Driven Ansible ルールブックは、ログファイルに対するアクションを支援するため、以下のコンポーネントで構成されています。

  • ソース: 使用するイベントソースを定義します。
  • ルール: イベントソースからどの条件が一致するかを定義します
  • アクション: 条件が満たされたときにイベントをトリガーします

次の例では、ルールブックは次のように 3 つのルールを含むルールセットを実装します。

ルール #1: トレイルの暗号化を有効にする

このルールは、トレイルの暗号化が無効になっている場合に対応します。これは、トレイルに対して UpdateTrail 操作が実行され、UpdateTrail 要求に含まれるパラメーターが次の条件に一致するときにトリガーされます。

event.CloudTrailEvent.requestParameters.kmsKeyId=="" であり、かつ event.CloudTrailEvent.requestParameters.name==vars.cloudtrail_name. と一致する

このドリフトを軽減するために実行されるアクションは、

'playbooks/eda/aws_restore_cloudtrail_encryption.yml playbook` を実行します。この Playbook は、トレイルの暗号化を再有効化してシステムを元の状態に復元する、Ansible 検証済みロール cloud.aws_ops.enable_cloudtrail_encryption_with_kms を実行します。

ルール #2: トレイルの再作成

このルールは、トレイルが削除された場合に対応します。

以下の条件が満たされた場合:

event.CloudTrailEvent.eventName=="DeleteTrail" であり、かつ event.CloudTrailEvent.requestParameters.name==vars.cloudtrail_name と一致する

アクションとして、playbooks/eda/aws_restore_cloudtrail.yml Playbook を実行します。この Playbook は、まず Ansible 検証済みコンテンツ cloud.aws_ops.awsconfig_multiregion_cloudtrail ロールを実行してトレイルを再作成し、次に cloud.aws_ops.enable_cloudtrail_encryption_with_kms ロールを実行して、新しく作成されたトレイルの暗号化を有効にします。

ルール #3: KMS キーの削除をキャンセルし、再度有効にする

このルールは、KMS キーが削除または無効化された場合に対応します。これにより、条件は以下のようになります。

event.CloudTrailEvent.eventName=="ScheduleKeyDeletion" または event.CloudTrailEvent.eventName=="DisableKey"

誰かが意図的または偶発的に KMS キーを削除しようとすると、AWS CloudTrail に ScheduleKeyDeletion イベントが表示されます。KMS キーを削除すると破壊的になり、潜在的な危険性があるため、KMS キーはすぐには削除されません。AWS KMS では、7 - 30 日間の待機期間を設定する必要があります。この状況は、playbooks/eda/aws_restore_kms_key.yml Playbook を実行して KMS キーの削除をキャンセルすることですぐに処理されます。同様に、KMS キーが無効が無効化されると、Playbook はそれを再有効化してシステムの元の状態に復元します。Playbook は KMS キー ARN を設定し、それを使用して KMS キーの削除をキャンセルするか、KMS キーを再度有効化するか、またはその両方を行うかを決定します。

cloud.aws_ops 向けの Ansible 検証済みコンテンツと Event-Driven Ansible は、クラウドコンピューティング環境における問題の自動解決や監視のための多くの機会を創出します。これにより、自動化を容易にし、セキュリティー問題を軽減して、クラウド環境の習熟度を最大限に高めることができます。ルールブックの使用に関する詳細は、Validated content for Event-Driven ansible for AWS を参照してください。

法律上の通知

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat