翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# セキュリティ検出結果のトリアージと修復の例
<a name="triage-remediation-examples"></a>

このセクションでは、セキュリティ、クラウド、アプリケーションチームのトリアージプロセスの例を示します。ここでは、各チームが一般的に対処する検出結果のタイプについて説明し、対応方法の例を示します。大まかな修復ガイダンスも含まれています。

**Topics**
+ [セキュリティチームの例: Security Hub CSPM 自動化ルールの作成](security-team-example.md)
+ [クラウドチームの例: VPC 設定の変更](cloud-team-example.md)
+ [アプリケーションチームの例: AWS Config ルールの作成](application-team-example.md)

# セキュリティチームの例: Security Hub CSPM 自動化ルールの作成
<a name="security-team-example"></a>

セキュリティチームは、Amazon GuardDuty の検出結果など、脅威の検出に関連する検出結果を受け取ります。 AWS リソースタイプ別に分類された GuardDuty 検出結果タイプの詳細なリストについては、GuardDuty ドキュメントの[「検出結果タイプ](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html)」を参照してください。セキュリティチームは、これらのすべての検出結果タイプに精通している必要があります。

この例では、セキュリティチームは、学習目的で厳密に AWS アカウント 使用され、重要なデータや機密データを含まない のセキュリティ検出結果に関連するリスクのレベルを受け入れています。このアカウントの名前は `sandbox` で、アカウント ID は `123456789012` です。セキュリティチームは、このアカウントからのすべての GuardDuty 検出結果を抑制する AWS Security Hub CSPM 自動化ルールを作成できます。多くの一般的なユースケースをカバーするテンプレートからルールを作成することも、カスタムルールを作成することもできます。Security Hub CSPM では、条件の結果をプレビューして、ルールが意図した検出結果を返すことを確認することをお勧めします。

**注記**  
この例では、自動化ルールの機能に焦点を当てています。アカウントのすべての GuardDuty 検出結果を抑制することはお勧めしません。コンテキストは重要であり、各組織はデータ型、分類、緩和コントロールに基づいて抑制する検出結果を選択する必要があります。

この自動化ルールの作成に使用されるパラメータを次に示します。
+ **ルール:**
  + **ルール名**は `Suppress findings from Sandbox account` です
  + **ルールの説明**は `Date: 06/25/23 Authored by: John Doe Reason: Suppress GuardDuty findings from the sandbox account` です
+ **条件:**
  + `AwsAccountId` = `123456789012`
  + `ProductName` = `GuardDuty`
  + `WorkflowStatus` = `NEW`
  + `RecordState` = `ACTIVE`
+ **自動アクション:**
  + `Workflow.status` は `SUPPRESSED`

詳細については、Security Hub CSPM ドキュメントの[「オートメーションルール](https://docs.aws.amazon.com/securityhub/latest/userguide/automation-rules.html)」を参照してください。セキュリティチームには、検出された脅威の検出結果を調査および修復するための多くのオプションがあります。詳細なガイダンスについては、「[AWS Security Incident Response テクニカルガイド](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)」を参照してください。このガイドを確認して、強力なインシデント対応プロセスが確立されていることを確認することをお勧めします。

# クラウドチームの例: VPC 設定の変更
<a name="cloud-team-example"></a>

クラウドチームは、ユースケースに合わない AWS デフォルト設定の変更など、一般的な傾向を持つセキュリティ検出結果の優先順位付けと修復を担当します。これらの検出結果は、VPC 設定などの多くの AWS アカウント またはリソースに影響を与える傾向があり、環境全体に配置する必要がある制限が含まれています。ほとんどの場合、クラウドチームはポリシーの追加や更新など、手動による 1 回限りの変更を行います。

組織が AWS 環境をしばらく使用した後、一連のアンチパターンが開発されている場合があります。*アンチパターン*とは、繰り返し起こる問題に対して頻繁に用いられる解決策で、その解決策が逆効果であったり、効果がなかったり、代替案よりも効果が低かったりするものです。これらのアンチパターンの代わりに、組織は AWS Organizations サービスコントロールポリシー (SCPs) や IAM Identity Center アクセス許可セットなど、より効果的な環境全体の制限を使用できます。SCP とアクセス許可セットは、ユーザーがパブリックな Amazon Simple Storage Service (Amazon S3) バケットを設定できないようにするなど、リソースタイプに対する追加の制限を提供することができます。すべての考え得るセキュリティ設定を制限したくなることもありますが、SCP とアクセス許可セットにはポリシーサイズ制限があります。予防的コントロールと検出的コントロールには、バランスの取れたアプローチをお勧めします。

以下は、クラウドチームが担当する AWS Security Hub CSPM [可能性のある基盤セキュリティベストプラクティス (FSBP)](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html) 標準のコントロールです。
+ [[EC2.2] VPC のデフォルトのセキュリティグループは、インバウンドトラフィックとアウトバウンドトラフィックを許可しないでください](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-2)
+ [[EC2.6] VPC フローログ記録はすべての VPCsで有効にする必要があります](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-6)
+ [[EC2.23] Amazon EC2 Transit Gateway は VPC アタッチメントリクエストを自動的に受け入れないでください](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-23)
+ [[CloudTrail.1] CloudTrail を有効にし、読み取りおよび書き込み管理イベントを含む少なくとも 1 つのマルチリージョン証跡を設定する必要があります](https://docs.aws.amazon.com/securityhub/latest/userguide/cloudtrail-controls.html#cloudtrail-1)
+ [[Config.1] AWS Config を有効にする必要があります](https://docs.aws.amazon.com/securityhub/latest/userguide/config-controls.html#config-1)

この例では、クラウドチームが FSBP コントロール EC2.2 の検出結果に対処しています。このコントロールの[ドキュメント](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-2)では、デフォルトのインバウンドルールとアウトバウンドルールによって広範なアクセスが許可されるため、デフォルトのセキュリティグループを使用しないことが推奨されています。デフォルトのセキュリティグループは削除できないため、ルール設定を変更して、インバウンドトラフィックとアウトバウンドトラフィックを制限することが推奨されています。この問題に効率的に対処するには、各 VPC にこのデフォルトのセキュリティグループがあるため、クラウドチームは確立されたメカニズムを使用してすべての VPC のセキュリティグループルールを変更する必要があります。ほとんどの場合、クラウドチームは [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) のカスタマイズや、[https://www.terraform.io/](https://www.terraform.io/)、[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) などの Infrastructure as Code (IaC) ツールを使用して VPC 設定を管理します。

# アプリケーションチームの例: AWS Config ルールの作成
<a name="application-team-example"></a>

以下は、アプリケーションまたは開発チームが担当する Security Hub CSPM [Foundational Security Best Practices (FSBP)](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html) セキュリティ標準のコントロールです。
+ [[CloudFront.1] CloudFront ディストリビューションにはデフォルトのルートオブジェクトが設定されている必要があります](https://docs.aws.amazon.com/securityhub/latest/userguide/cloudfront-controls.html#cloudfront-1)
+ [[EC2.19] セキュリティグループは、高リスクのポートへの無制限アクセスを許可しないでください](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-19)
+ [[CodeBuild.1] CodeBuild GitHub または Bitbucket ソースリポジトリ URLsは OAuth を使用する必要があります](https://docs.aws.amazon.com/securityhub/latest/userguide/codebuild-controls.html#codebuild-1)
+ [[ECS.4] ECS コンテナは非特権として実行する必要があります](https://docs.aws.amazon.com/securityhub/latest/userguide/ecs-controls.html#ecs-4)
+ [[ELB.1] Application Load Balancer は、すべての HTTP リクエストを HTTPS にリダイレクトするように設定する必要があります](https://docs.aws.amazon.com/securityhub/latest/userguide/elb-controls.html#elb-1)

この例では、アプリケーションチームが FSBP コントロール EC2.19 の検出結果に対処しています。このコントロールは、指定した高リスクのポートにセキュリティグループの受信 SSH トラフィックがアクセス可能かどうかをチェックします。セキュリティグループ内のルールがこれらのポートについて、`0.0.0.0/0` または `::/0` からの着信トラフィックを許可している場合、このコントロールは失敗します。このコントロールの[ドキュメント](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-19)では、このトラフィックを許可するルールを削除することを推奨しています。

個々のセキュリティグループルールに対処することに加えて、これは新しい AWS Config [ルール](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)になる結果の優れた例です。[プロアクティブ評価モード](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config-rules.html#aws-config-rules-evaluation-modes)を使用すると、将来的にリスクの高いセキュリティグループルールのデプロイを防ぐことができます。プロアクティブモードでは、リソースがデプロイされる前に評価されるため、リソースの設定ミスや関連するセキュリティ検出結果を防ぐことができます。新しいサービスまたは新機能を実装する場合、アプリケーションチームは継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインの一部としてプロアクティブモードでルールを実行して、非準拠リソースを特定できます。次の図は、プロアクティブ AWS Config ルールを使用して、 AWS CloudFormation テンプレートで定義されたインフラストラクチャが準拠していることを確認する方法を示しています。



![\[AWS CloudFormation テンプレートのコンプライアンスをチェックするプロアクティブ AWS Config ルール\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/vulnerability-management/images/cloudformation-config-proactive-workflow.png)


この例では、もう 1 つの重要な効率向上が得られます。アプリケーションチームがプロアクティブ AWS Config ルールを作成すると、他のアプリケーションチームがそれを使用できるように、共通のコードリポジトリで共有できます。

Security Hub CSPM コントロールに関連付けられた各検出結果には、検出結果の詳細と、問題を修正する手順へのリンクが含まれています。クラウドチームは、1 回限りの手動修復を必要とする検出結果に遭遇する可能性がありますが、必要に応じて、開発プロセスのできるだけ早い段階で問題を特定するプロアクティブチェックを構築することをお勧めします。