Amazon Web Services ブログ
Security Hub CSPM から Security Hub への自動化ルール移行ガイド
本ブログは 2025 年 12 月 17 日に公開された AWS Blog “Security Hub CSPM automation rule migration to Security Hub” を翻訳したものです。
AWS Security Hub の新しいバージョンの一般提供が開始されました。このバージョンでは、Amazon Web Services (AWS) アカウント全体のセキュリティアラートを集約、相関付け、コンテキスト化する新機能が追加されています。旧バージョンは AWS Security Hub CSPM として引き続き利用可能で、クラウドセキュリティポスチャ管理と検出結果の集約に特化した独立したサービスとして提供されます。
両方のサービスで利用できる機能の 1 つが自動化ルールです。Security Hub と Security Hub CSPM のどちらでも、自動化ルールを使用して、定義した条件が満たされたときに検出結果のフィールドを自動的に更新できます。Security Hub では、自動化ルールを使用して検出結果をサードパーティプラットフォームに送信し、運用対応を行うこともできます。既存の Security Hub CSPM ユーザーの多くは、本番リソースに影響する検出結果の重要度を上げたり、修復ワークフローを支援するコメントを追加したりするタスクに自動化ルールを使用しています。両方のサービスで同様の自動化ルール機能が提供されていますが、ルールは 2 つのサービス間で同期されません。新しい Security Hub の導入を検討している既存の Security Hub CSPM のお客様は、すでに構築した自動化ルールの移行に関心があるかもしれません。これにより、検出結果の確認と自動化ルールの処理を同じ場所で行えるようになります。本ブログの公開時点 (2025 年 12 月 17 日) では、この機能は Security Hub エッセンシャルプランの料金に含まれています。最新の料金の詳細については、Security Hub の料金ページを参照してください。
この記事では、Security Hub CSPM から Security Hub に自動化ルールを自動的に移行するソリューションを紹介します。これにより、新しい Security Hub の機能を活用しながら、セキュリティ自動化ワークフローを維持できます。現在自動化ルールを使用しておらず、これから始めたい場合は、Security Hub の自動化ルールを参照してください。
自動化ルール移行の課題
Security Hub CSPM は、検出結果のスキーマとして AWS Security Finding Format (ASFF) を使用しています。このスキーマは、検出結果が生成されたときに自動化ルールがどのように適用されるかの基盤となっています。自動化ルールは、まず 1 つ以上の条件を定義し、次に指定した条件が満たされたときに適用される 1 つ以上のアクションを選択することで作成します。各条件では、ASFF フィールド、演算子 (equals や contains など)、および値を指定します。アクションは 1 つ以上の ASFF フィールドを更新します。
新バージョンの Security Hub は、Open Cybersecurity Schema Framework (OCSF) を使用しています。これは、AWS とサイバーセキュリティ業界のパートナーがサポートする、広く採用されているオープンソーススキーマです。Security Hub の自動化ルールは、構造的には Security Hub CSPM のルールと同じように機能しますが、基盤となるスキーマの変更により、既存の自動化ルールには変換が必要です。
この記事で紹介するソリューションは、Security Hub CSPM の自動化ルールを自動的に検出し、OCSF スキーマに変換し、新バージョンの Security Hub を実行している AWS アカウントにデプロイするための AWS CloudFormation テンプレートを作成します。ASFF と OCSF スキーマには本質的な違いがあるため、一部のルールは自動的に移行できず、移行後に手動でのレビューが必要になる場合があります。
以下の表は、条件としてサポートされている ASFF フィールドと、対応する OCSF フィールドの現在のマッピングを示しています。これらのマッピングは、将来のサービスリリースで変更される可能性があります。N/A と記載されているフィールドは移行できないため、自動化ルールを移行する際には特別な考慮が必要です。これらは新しい Security Hub で再設計する必要があります。この記事で紹介するソリューションは、OCSF フィールドにマッピングされない ASFF 条件が 1 つ以上あるルールの移行をスキップするように設計されていますが、レビュー用のレポートでそれらのルールを特定します。
| ASFF のルール条件 | 対応する OCSF フィールド |
AwsAccountId |
cloud.account.uid |
AwsAccountName |
cloud.account.name |
CompanyName |
metadata.product.vendor_name |
ComplianceAssociatedStandardsId |
compliance.standards |
ComplianceSecurityControlId |
compliance.control |
ComplianceStatus |
compliance.status |
Confidence |
confidence_score |
CreatedAt |
finding_info.created_time |
Criticality |
N/A |
Description |
finding_info.desc |
FirstObservedAt |
finding_info.first_seen_time |
GeneratorId |
N/A |
Id |
finding_info.uid |
LastObservedAt |
finding_info.last_seen_time |
NoteText |
comment |
NoteUpdatedAt |
N/A |
NoteUpdatedBy |
N/A |
ProductArn |
metadata.product.uid |
ProductName |
metadata.product.name |
RecordState |
activity_name |
RelatedFindingsId |
N/A |
RelatedFindingsProductArn |
N/A |
ResourceApplicationArn |
N/A |
ResourceApplicationName |
N/A |
ResourceDetailsOther |
N/A |
ResourceId |
resources[x].uid |
ResourcePartition |
resources[x].cloud_partition |
ResourceRegion |
resources[x].region |
ResourceTags |
resources[x].tags |
ResourceType |
resources[x].type |
SeverityLabel |
vendor_attributes.severity |
SourceUrl |
finding_info.src_url |
Title |
finding_info.title |
Type |
finding_info.types |
UpdatedAt |
finding_info.modified_time |
UserDefinedFields |
N/A |
VerificationState |
N/A |
WorkflowStatus |
status |
以下の表は、アクションとしてサポートされている ASFF フィールドと、対応する OCSF フィールドを示しています。一部のアクションフィールドは OCSF では利用できない点にご注意ください。
| ASFF のルールアクションフィールド | 対応する OCSF フィールド |
Confidence |
N/A |
Criticality |
N/A |
Note |
Comment |
RelatedFindings |
N/A |
Severity |
Severity |
Types |
N/A |
UserDefinedFields |
N/A |
VerificationState |
N/A |
Workflow Status |
Status |
OCSF に対応するフィールドがないアクションを含む Security Hub CSPM の自動化ルールについては、このソリューションはルールを移行しますが、サポートされているアクションのみを含めます。これらのルールは、ルールの説明と移行レポートで「partially migrated」(部分的に移行) と表示されます。この情報を活用して、ルールを有効にする前にレビューおよび変更し、新しい自動化ルールが期待どおりに動作することを確認してください。
ソリューションの概要
このソリューションは、Security Hub CSPM から新しい Security Hub への自動化ルールの移行を支援する Python スクリプトのセットを提供します。移行プロセスは以下のように動作します。
- 移行の開始: このソリューションは、3 つのサブスクリプトを起動し、適切な入力を渡すオーケストレーションスクリプトを提供します
- 検出: このソリューションは、Security Hub CSPM 環境をスキャンして、指定した AWS リージョン全体の既存の自動化ルールを特定して収集します
- 分析: 各ルールは、ASFF から OCSF へのフィールドマッピングの互換性に基づいて、完全に移行できるか、部分的に移行できるか、または手動での対応が必要かを判断するために評価されます
- 変換: 互換性のあるルールは、事前定義されたフィールドマッピングを使用して、ASFF スキーマから OCSF スキーマに自動的に変換されます
- テンプレートの作成: このソリューションは、変換されたルールを含む CloudFormation テンプレートを生成し、元のルールの順序とリージョンのコンテキストを維持します
- デプロイ: 生成されたテンプレートをレビューし、デプロイして Security Hub に移行されたルールを作成します。ルールはデフォルトで無効状態で作成されます
- ルールの検証と有効化: Security Hub の AWS マネジメントコンソールで移行された各ルールをレビューし、条件、アクション、および該当する場合は現在一致する検出結果のプレビューを確認します。ルールが個別に、またシーケンスとして意図したとおりに動作することを確認した後、ルールを有効にして自動化ワークフローを再開します
図 1: スクリプトと AWS との連携を示すアーキテクチャ図
図 1 に示すソリューションは、自動化ルールを移行するために連携して動作する 4 つの Python スクリプトで構成されています。
- Orchestrator: 検出、変換、生成をレポートとログ記録とともに調整します
- Rule discovery: 指定したリージョン全体で Security Hub CSPM から既存の自動化ルールを特定して抽出します
- Schema transformation: 前述のフィールドマッピングを使用して、ルールを ASFF から OCSF 形式に変換します
- Template generation: 移行されたルールをデプロイするために使用できる CloudFormation テンプレートを作成します
これらのスクリプトは、AWS Command Line Interface (AWS CLI) を使用して設定された認証情報で、既存の Security Hub 自動化ルールを検出します。AWS CLI を使用した認証情報の設定方法の詳細については、AWS CLI のセットアップを参照してください。
前提条件
ソリューションを実行する前に、以下のコンポーネントと権限が整っていることを確認してください。
- 必要なソフトウェア:
- AWS CLI (最新バージョン)
- Python 3.12 以降
- Python パッケージ:
- boto3 (最新バージョン)
- pyyaml (最新バージョン)
- 必要な権限:
ルールの検出と変換に必要な権限:- securityhub:ListAutomationRules
- securityhub:BatchGetAutomationRules
- securityhub:GetFindingAggregator
- securityhub:DescribeHub
- securityhub:ListAutomationRulesV2
テンプレートのデプロイに必要な権限:
- cloudformation:CreateStack
- cloudformation:UpdateStack
- cloudformation:DescribeStacks
- cloudformation:CreateChangeSet
- cloudformation:DescribeChangeSet
- cloudformation:ExecuteChangeSet
- cloudformation:GetTemplateSummary
- securityhub:CreateAutomationRuleV2
- securityhub:UpdateAutomationRuleV2
- securityhub:DeleteAutomationRuleV2
- securityhub:GetAutomationRuleV2
- securityhub:TagResource
- securityhub:ListTagsForResource
AWS アカウントの設定
Security Hub は、AWS Organizations と併用する場合、委任管理者アカウントモデルをサポートしています。委任管理者アカウントは、組織のメンバーアカウント全体のセキュリティ検出結果とサービス設定を一元管理します。自動化ルールは、ホームリージョンおよびリンクされていないリージョンの委任管理者アカウントで作成する必要があります。メンバーアカウントは独自の自動化ルールを作成できません。
AWS では、一貫したセキュリティ管理を維持するために、Security Hub CSPM と Security Hub の両方で同じアカウントを委任管理者として使用することを推奨しています。移行ソリューションを実行する前に、この委任管理者アカウントの認証情報を使用して AWS CLI を設定してください (詳細については、AWS CLI のセットアップを参照してください)。
このソリューションは主に委任管理者のデプロイ向けに設計されていますが、単一アカウントの Security Hub 実装もサポートしています。
移行の主要な概念
Security Hub CSPM から Security Hub への自動化ルールの移行を進める前に、ルールの移行とデプロイに影響するいくつかの重要な概念を理解しておくことが大切です。これらの概念は移行プロセスとルールの動作に影響するため、理解しておくことで移行戦略の計画と結果の検証を効果的に行えます。
デフォルトのルール状態
デフォルトでは、移行されたルールは DISABLED 状態で作成されます。つまり、検出結果が生成されてもアクションは適用されません。このソリューションでは、オプションでルールを ENABLED 状態で作成することもできますが、これは推奨されません。代わりに、ルールを DISABLED 状態で作成し、各ルールをレビューして一致する検出結果をプレビューしてから、準備ができたらルールを ENABLED 状態に変更してください。
サポートされていないフィールド
移行レポートには、新しい Security Hub でサポートされていない Security Hub CSPM の条件が 1 つ以上含まれているために移行できないルールの詳細が記載されます。これらのケースは、ASFF と OCSF スキーマの違いによって発生します。同等の動作を自動的に再現できないため、これらのルールには特別な注意が必要です。特に、優先順位に依存する Security Hub CSPM ルールがある場合は重要です。
サポートされていないアクションがあるルールでも、少なくとも 1 つのアクションがサポートされていれば移行されます。部分的にサポートされているアクションを持つルールは、移行レポートと新しい自動化ルールの説明でフラグが付けられるため、レビューが必要です。
ホームリージョンとリンクされたリージョン
Security Hub CSPM と Security Hub はどちらも、リンクされたリージョンからの検出結果を集約するホームリージョンをサポートしています。ただし、自動化ルールの動作は異なります。Security Hub CSPM の自動化ルールはリージョン単位で動作し、ルールが作成されたリージョンで生成された検出結果にのみ影響します。ホームリージョンを使用している場合でも、Security Hub CSPM の自動化ルールは、ホームリージョンでリンクされたリージョンから集約された検出結果には適用されません。一方、Security Hub は、ホームリージョンで定義してすべてのリンクされたリージョンに適用される自動化ルールをサポートしており、リンクされたリージョンでの自動化ルールの作成はサポートしていません。ただし、Security Hub では、リンクされていないリージョンは独自の自動化ルールを持つことができ、そのリージョンで生成された検出結果にのみ影響します。リンクされていないリージョンには、自動化ルールを個別に適用する必要があります。
このソリューションは、これらの違いに対応するために 2 つのデプロイモードをサポートしています。最初のモードはホームリージョンモードと呼ばれ、ホームリージョンが有効になっている Security Hub のデプロイに使用します。このモードでは、指定したリージョンから Security Hub CSPM の自動化ルールを特定し、ルールの元のリージョンを考慮した追加の条件を付けて再作成します。その後、ホームリージョンにデプロイできる 1 つの CloudFormation テンプレートが生成されます。元のリージョンの条件が追加されているため、自動化ルールは意図したとおりに動作します。
2 番目のモードはリージョン別モードと呼ばれます。このモードは、現在ホームリージョンを使用していないユーザー向けです。このモードでも、指定したリージョンの自動化ルールを検出しますが、各リージョンに対して個別の CloudFormation テンプレートを生成します。生成されたテンプレートは、対応するリージョンの委任管理者アカウントに 1 つずつデプロイできます。このモードでは、自動化ルールに追加の条件は追加されません。
Security Hub でホームリージョンを使用し、一部のリージョンをリンクしているが、すべてではない場合もあります。この場合は、ホームリージョンとすべてのリンクされたリージョンに対してホームリージョンモードを実行します。次に、すべてのリンクされていないリージョンに対してリージョン別モードでソリューションを再実行します。
ルールの順序
Security Hub CSPM と Security Hub の自動化ルールには、どちらも評価される順序があります。これは、異なる自動化ルールが同じ検出結果に適用されたり、同じフィールドに対してアクションを実行したりする可能性がある特定の状況で重要になることがあります。このソリューションは、自動化ルールの元の順序を維持します。
既存の Security Hub 自動化ルールがある場合、このソリューションは既存のルールの後から新しい自動化ルールを作成します。たとえば、3 つの Security Hub 自動化ルールがあり、10 個の新しいルールを移行する場合、ソリューションは新しいルールに 4 から 13 の順序を割り当てます。
ホームリージョンモードを使用する場合、各リージョンの自動化ルールの順序は維持され、最終的な順序でまとめてグループ化されます。たとえば、3 つの異なるリージョンに 3 つの Security Hub 自動化ルールを持つユーザーがルールを移行する場合、ルールは順番に移行されます。ソリューションは、まずリージョン 1 のすべてのルールを元の順序で移行し、次にリージョン 2 のすべてのルールを元の順序で移行し、最後にリージョン 3 のすべてのルールを元の順序で移行します。
移行のデプロイと検証
前提条件が整い、基本的な概念を理解したら、移行をデプロイして検証する準備ができました。
移行をデプロイする手順
1. AWS samples GitHub リポジトリから Security Hub 自動化ルール移行ツールをクローンします。
git clone https://github.com/aws-samples/sample-SecurityHub-Automation-Rule-Migration.git
2. README ファイルの手順に従ってスクリプトを実行します。README ファイルには最新の実装手順が記載されています。これにより、新しい Security Hub 自動化ルールを作成する CloudFormation テンプレートが生成されます。AWS CLI またはコンソールを使用して CloudFormation テンプレートをデプロイします。詳細については、CloudFormation コンソールからスタックを作成するまたは README ファイルを参照してください。
デプロイが完了したら、Security Hub コンソールを使用して移行された自動化ルールを確認できます。ルールはデフォルトで DISABLED 状態で作成されることに注意してください。各ルールの条件とアクションを慎重に確認し、意図した自動化ワークフローと一致していることを確認してください。コンソールで、各自動化ルールに一致する既存の検出結果をプレビューすることもできます。
移行されたルールを確認して検証するには:
1. Security Hub コンソールに移動し、ナビゲーションペインから [Automations] (オートメーション) を選択します。
図 2: Security Hub の Automations ページ
2. ルールを選択し、ページ上部の [Edit] (編集) を選択します。
図 3: Security Hub 自動化ルールの詳細
3. [Preview matching findings] (一致する検出結果をプレビューしてください) を選択します。自動化ルールが期待どおりに動作していても、検出結果が返されない場合があります。これは、現在 Security Hub にルールの条件に一致する検出結果がないことを意味します。この場合でも、ルールの条件を確認できます。
図 4: Security Hub の自動化ルール編集ページ
4. ルールの設定を検証した後、ルール編集ページからコンソールを通じてルールを有効にできます。CloudFormation スタックを更新することもできます。自動化ルールの条件やアクションを変更する必要がなかった場合は、オプションの —create-enabled フラグを付けてスクリプトを再実行し、すべてのルールが有効な状態の CloudFormation テンプレートを再生成して、既存のスタックの更新としてデプロイできます。
partially migrated actions (部分的に移行されたアクション) となっているルールに注意してください。これは各ルールの [Description] に記載されています。Security Hub CSPM の元のルールの 1 つ以上のアクションが Security Hub でサポートされておらず、ルールが意図したとおりに動作しない可能性があることを意味します。このソリューションは、どのルールが部分的に移行されたか、元のルールのどのアクションが移行できなかったかを示す移行レポートも生成します。これらのルールは期待どおりに動作しない可能性があり、変更または再作成が必要な場合があるため、慎重に確認してください。
図 5: 部分的に移行された自動化ルールの説明を確認する
まとめ
新しい AWS Security Hub は、セキュリティ検出結果の集約、相関付け、コンテキスト化のための強化された機能を提供します。ASFF から OCSF へのスキーマ変更により、相互運用性と統合オプションが向上しますが、既存の自動化ルールの移行が必要になります。この記事で紹介したソリューションは、既存のルールを検出し、新しいスキーマに変換し、ルールの順序とリージョンのコンテキストを維持する CloudFormation テンプレートを実行することで、この移行プロセスを自動化します。
自動化ルールを移行した後は、まず移行レポートを確認して、完全に移行されなかったルールを特定してください。部分的に移行されたとマークされたルールには特に注意が必要です。これらは元のバージョンとは異なる動作をする可能性があります。各ルールを無効状態でテストし、特に同じフィールドに対して操作するルールについては、ルールが期待どおりに連携して動作することを検証してから、環境で有効にすることをお勧めします。
Security Hub とその強化された機能の詳細については、Security Hub ユーザーガイドを参照してください。