関連ユーザ
ユーザRole
|
アクセス可能
|
テクニカルチームメンバー
|
![]() |
DevOpsチームメンバー
|
![]() |
セキュリティアナリスト
|
|
セキュリティエンジニア
|
![]() |
コンプライアンスマネージャ
|
|
プロジェクトマネージャ
|
|
セキュリティチーム管理
|
![]() |
コンサルタント
|
![]() |
例
- 私の会社は最近、既存のクラウドプロジェクトの責任を負うことになりました。私はそれが安全でベストプラクティスに準拠していることを確認したいと考えています。
- 私たちのAWSプロジェクトは、手動でセキュリティ状態を確保するのが難しいほどの規模に成長したため、よりスケーラブルなソリューションを求めています。
Cloud Conformityソリューション
開始する前に
パート1 - 現在のセキュリティ状態を評価するためのレポート作成
ステップ1. アカウントまたはアカウントのグループを選択してセキュリティ状態を評価し、All Checks reportを生成します。
ステップ2. フィルターを使用して、All Checksレポートを失敗したチェックでフィルタリングします。
ステップ3. 組織の優先順位に基づいて結果を絞り込むために、失敗したチェックをさらにフィルタリングしてレポートを作成します。例えば、Well-Architected
Frameworkのカテゴリ、リソースタグ、リソースタイトル、リスクレベルまたは失敗したチェックの重大度でフィルタリングできます。
例えば、以下のフィルターを適用すると、基本的なセキュリティレポートが作成されます。これにより、複数の失敗を一度に処理するよりも、焦点を絞って対処することが容易になります。
手順
- カテゴリ > セキュリティ
- タグ > "public"
- Standards and Frameworks > AWS Well-Architected Framework
- オプション: PDFまたはCSVの失敗したチェックレポートを生成してダウンロードし、関係者と共有します。
パート2 - レポートに基づいた修復計画の作成
ステップ1. レポートを分析して、さまざまなルールの障害を解決するためのチームメンバーの労力と可用性を見積もります。
ステップ2. 優先順位付けのために障害を異なるグループに分けます。
例えば、障害をグループ化する際には、最小の労力で済むルール、最も重大なルール、特定のサービスやカテゴリによるルールを優先することができます。これにより、優先順位に基づいて障害を分離し、解決するのに役立ちます。
高影響のサービス、EC2、RDS、S3、IAM、VPC、およびロードバランサーを優先し、その後、他のExtremeまたはVery Highの失敗チェックを続行することをお勧めします。
![]() |
ヒント修復シナリオの例:
|
ステップ3. フィルターを使用して、各グループのFailureのReportsをGenerateし、チームメンバーと共有します。各メンバーは、レポートの一部として送信された各Rule
Failureの修復手順に従うことができます。
オプション: 関係者に取り組みと進捗を知らせるために、定期レポートを作成することができます。