AWS Security Finding Format（ASFF）の実践活用例とベストプラクティス – Techfirm Cloud Architect Blog

企業テック

はじめに

以前の記事では、AWS Security HubでASFF（AWS Security Finding Format）を利用する際に必須となる最上位属性について解説しました。
今回はその続編として、ASFFを活用したセキュリティ運用のベストプラクティスを紹介します。
具体的には、Security Hubにおける Finding（検出結果） の仕組みを理解したうえで、カスタム検出結果の作成方法や自動化との連携による運用効率化についても取り上げ、ASFFを用いた実践的なセキュリティ対策の抑えるべきポイントを解説します。

Security Hubの「Finding」とは？

Finding（検出結果） とは、AWS Security Hubがセキュリティ上の懸念や問題を検出した際に記録する情報のことです。
たとえば、「パブリックアクセス可能なS3バケットが存在する」「過剰な権限を持つIAMポリシーがある」など、セキュリティリスクを示すイベントがFindingとして記録されます。

Security Hubは、AWSの各種サービスやサードパーティ製品、さらには独自の検出ロジックからの情報を統合し、Findingとして一元管理することでセキュリティ状況の可視化と対応を効率化します。

Findingの主な構成要素（ASFF）

Security Hubでは、Findingは ASFF（AWS Security Finding Format） という共通フォーマットで表現されます。以下は、とくに重要な構成要素です：

項目 説明
SchemaVersion 使用するASFFのバージョン（例：2018-10-08）
Id 一意の識別子（UUIDなど）
ProductArn 検出元の製品を示すARN
GeneratorId 検出を生成したロジックやツールの識別子
AwsAccountId 対象となるAWSアカウントID
Types 検出のカテゴリ（例：脆弱性、設定ミスなど）
CreatedAt / UpdatedAt 検出日時と更新日時
Severity 重大度（LOW / MEDIUM / HIGH / CRITICAL）
Title / Description 検出のタイトルと詳細説明
Resources 対象となるAWSリソース（例：EC2、S3など）

カスタム検出結果の作成

ASFFはAWSのサービスだけでなく、独自のセキュリティ検出ロジックを持つツールやスクリプトからも利用可能です。
たとえば、社内の脆弱性スキャンツールやログ分析ツールから得られた情報をASFFに変換し、Security Hubに送信することで、統合的な可視化が可能になります。

例：PythonでカスタムFindingを作成

import boto3
import uuid
import datetime

client = boto3.client('securityhub')

finding = {
    'SchemaVersion': '2018-10-08',
    'Id': str(uuid.uuid4()),
    
    
    
    'ProductArn': 'arn:aws:securityhub:us-east-1:123456789012:product/123456789012/default',
    'GeneratorId': 'custom-script',
    'AwsAccountId': '123456789012',
    'Types': ['Software and Configuration Checks/Vulnerabilities/CVE'],
    'CreatedAt': datetime.datetime.utcnow().isoformat() + 'Z',
    'UpdatedAt': datetime.datetime.utcnow().isoformat() + 'Z',
    'Severity': {'Label': 'HIGH'},
    'Title': 'Custom Vulnerability Detected',
    'Description': 'Detected vulnerability in internal system.',
    'Resources': [{
        'Type': 'AwsEc2Instance',
        'Id': 'i-0abcd1234efgh5678'
    }]
}

client.batch_import_findings(Findings=[finding])

ASFFと自動化の連携（Security Hub + EventBridge）

Security HubにFindingが登録されると、Amazon EventBridgeを通じて自動的に通知やアクションをトリガーできます。
たとえば：

  • 高リスクのFindingが発生したらSlackに通知
  • 特定のタグが付いたEC2インスタンスに対して自動隔離処理を実行
  • Lambda関数で自動修復処理を実行

このように、ASFFを起点としたセキュリティ自動化のパイプラインを構築することで、対応の迅速化と人的ミスの削減が期待できます。

Security HubにカスタムFindingを送信するときに押さえるべきベストプラクティス

AWS Security Hubでは、独自の検出ロジックや社内ツールから得られたセキュリティ情報を、ASFF（AWS Security Finding Format）に準拠した形式で送信できます。
以下は、 Security HubにカスタムFindingを送信する際 に推奨されるベストプラクティスです。

スキーマバージョンの明示

常に最新のスキーマバージョン（例：2018-10-08）を指定し、将来的な互換性を確保しましょう。

一意なIDの生成

Idは重複しないようにUUIDなどで生成し、Security Hubでの重複登録を防ぎます。
同じIDで複数回送信すると、最初の1件のみが処理されるため注意が必要です。

Resourcesの正確な指定

リソースのTypeやIdは正確に記述することで、Security HubのUI上でのフィルタリングや可視化が容易になります。
ASFFでは最大32件までのリソースを指定できます。

Severityの適切な設定

緊急度（LOW / MEDIUM / HIGH / CRITICAL）は、対応優先度の判断材料となるため、検出ロジックに応じて適切に設定しましょう。

タイムスタンプの明示

CreatedAtとUpdatedAtはISO 8601形式で明示的に指定する必要があります。
更新時にはUpdatedAtを変更することで、Security Hubが新しい情報として認識します。

ProductArnの正しい指定

カスタムインテグレーションの場合、以下の形式でProductArnを指定します：
arn:aws:securityhub:::product//default

出典

おわりに

ASFFは単なるフォーマットではなく、セキュリティ運用の中核を担うデータモデルです。
AWS Security Hubと連携することで、セキュリティイベントの可視化・統合・自動化が可能となり、より強固なクラウドセキュリティ体制を構築できます。




元の記事を確認する

ワインバーグの法則をAIに適用する『コンサルタントの秘密』 前の記事 外交映像のミーム動画化 ― SNS・AIが広げる外交情報空間と「揺さぶりが効かない日本社会」（佐藤仁） - エキスパート - Yahoo!ニュース 次の記事

関連記事