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

# Security Hub ポリシー使用のベストプラクティス
<a name="orgs_manage_policies_security_hub_best_practices"></a>

組織全体に Security Hub ポリシーを実装する場合、確立されたベストプラクティスに従うことで、セキュリティ設定のデプロイとメンテナンスを確実に成功させることができます。これらのガイドラインは、Security Hub ポリシーの管理と実施の固有の側面に特化しています AWS Organizations。

## ポリシー設計の原則
<a name="policy-design-principles"></a>

Security Hub ポリシーを作成する前に、ポリシー構造の明確な原則を確立します。ポリシーをシンプルに保ち、最終的な結果の判断を困難にする複雑な属性間ルールやネストされたルールを排除します。組織ルートレベルの広範なポリシーから着手し、必要に応じて子ポリシーを用いて絞り込んでいきます。

空のリージョンリストを戦略的に使用することを検討してください。特定のリージョンでのみ Security Hub を無効にしたい場合は、`enable_in_regions` を空のままにしておくか、リージョンがポリシーで管理されないように `disable_in_regions` を空のままにしておくことができます。こうした柔軟性により、セキュリティモニタリングカバレッジを正確にコントロールすることができます。

## リージョン管理戦略
<a name="region-management-strategies"></a>

Security Hub ポリシーを使用してリージョンを管理する場合は、以下に説明する実証済みのアプローチの採用を検討してください。将来発生するリージョンを自動的にセキュリティカバレッジに含めたい場合は、`ALL_SUPPORTED` を使用します。よりきめ細かな管理が必要であり、特にリージョンのセキュリティ要件がそれぞれ異なる場合は、`ALL_SUPPORTED` を使用するのではなく、リージョンを明示的にリストアップします。

特に以下について、リージョン固有の要件を文書化しておきます。
+ 特定の設定を必要とするコンプライアンスが必須のリージョン
+ 開発環境と本番環境の違い
+ 特別な考慮事項があるオプトインリージョン
+ Security Hub を無効にしておく必要があるリージョン

## ポリシー継承のプランニング
<a name="policy-inheritance-planning"></a>

ポリシー継承構造を慎重にプランニングすることで、必要な柔軟性を確保しながら、効果的なセキュリティコントロールを維持します。継承されたポリシーを変更できる組織単位と、許可される変更内容を文書化します。厳格なセキュリティコントロールを適用する必要がある場合は、継承演算子 (@@assign、@@append、@@remove) を親レベルで制限することを検討してください。

## モニタリングと評価
<a name="monitoring-validation"></a>

定期的なモニタリングプラクティスの実装により、ポリシーの継続的な有効性を確保します。特に組織の変更が行われた際には、ポリシーの添付ファイルを定期的に確認してください。特に `ALL_SUPPORTED` を使用する場合や複数のリージョンリストを管理する場合は、リージョン設定が意図されるセキュリティカバレッジと一致することを確認します。

## トラブルシューティング戦略
<a name="troubleshooting-strategies"></a>

Security Hub ポリシーをトラブルシューティングするときは、まずポリシーの優先順位と継承設定に焦点を当てます。リージョンが無効化設定と有効化設定の両方のリストに表示される場合、無効化設定が有効化設定よりも優先されることに注意してください。ポリシー継承チェーンをチェックして、親ポリシーと子ポリシーを組み合わせて各アカウント向けに効果的なポリシーを作成する方法を理解します。