- 公開日
- 最終更新日
【AWS セキュリティ成熟度モデルを読み解く】 - クイックウィン
この記事を共有する
パーソル＆サーバーワークスの髙井です。
AWS を中心としたクラウドインフラの設計・構築・運用を担当しています。
はじめに
本ブログは「AWS セキュリティ成熟度モデルを読み解く」シリーズの第1回です。
AWS セキュリティ成熟度モデル v2 は、AWS のセキュリティスペシャリストチームが作成した規範的なガイダンスで、クラウド活用のあらゆる段階で組織のセキュリティ対策状況を強化するための推奨アクションに優先順位をつけることを目的としています。
Well-Architected Framework や AWS CAF（Cloud Adoption Framework）と推奨事項自体は整合していますが、成熟度モデルならではの特徴として「何を先にやるべきか」という優先順位付けの観点と、実装の詳細が含まれている点が挙げられます。
モデルは4つのフェーズに分かれています。
- クイックウィン -- 1〜2週間で実施可能、コスト効率が高く効果が大きい
- 基礎 -- クイックウィンより労力はかかるが、非常に重要なコントロール
- 効率化 -- セキュリティ運用を仕組み化・自動化するフェーズ
- 最適化 -- 成熟した組織がさらに高度な対策を講じるフェーズ
本シリーズでは、各フェーズの推奨事項をわかりやすく要約し、紹介していきます。
第1回となる今回は「クイックウィン」を取り上げます。
想定読者 - AWS を業務で利用しており、セキュリティ対策の優先順位付けに悩んでいるエンジニアや情シス担当者 - 「まず何からやればいいのか」を知りたい方
クイックウィンとは
クイックウィンは、実施や有効化が簡単で、組織のセキュリティ対策状況を大幅に改善できる機能や設定のことです。
いわゆる「すぐに取り組める改善点」で、ほとんどの組織で1〜2週間以内に実施可能とされています。
成熟度モデルでは、クイックウィンの推奨事項を下記の10カテゴリに分類しています。
- セキュリティガバナンス
- セキュリティ保証
- アイデンティティとアクセス管理
- 脅威検知
- 脆弱性管理
- インフラストラクチャ保護
- データ保護
- アプリケーションセキュリティ
- インシデントレスポンス
- レジリエンス
本ブログで取り上げるカテゴリについて
本シリーズでは、10カテゴリの中から多くの組織に当てはまる（汎用性が高い）4カテゴリに絞り、全4回を通じて統一的に取り上げます。
| カテゴリ | 概要 |
|---|---|
| アイデンティティとアクセス管理 | 「誰が何にアクセスできるか」は規模・業種を問わず全組織に共通する最も基本的な課題です |
| 脅威検知 | 脅威に気づけなければ対処もできません。検知の仕組みはすべての AWS 環境で必要です |
| データ保護 | データを扱わないシステムは存在しません。漏洩・改ざんの防止は全組織の責務です |
| インシデントレスポンス | 「インシデントは起きる」前提での備えは、組織の成熟度に関係なく必要です |
同じ4カテゴリをフェーズごとに追うことで、セキュリティ対策が段階的にどう進化していくかを感じ取っていただけると思います。
本ブログで取り上げるクイックウィン一覧
| カテゴリ | 推奨事項 | 概要 |
|---|---|---|
| アイデンティティとアクセス管理 | 多要素認証（MFA） | ルートユーザー・IAM ユーザーの MFA 有効化 |
| 脅威検知 | 基本の脅威検出 | Amazon GuardDuty による脅威の自動検出 |
| データ保護 | パブリックアクセスのブロック | S3、AMI、EBS スナップショットのパブリックアクセスを遮断 |
| インシデントレスポンス | 重大なセキュリティ検出結果への対応 | CRITICAL/HIGH の検出結果への対応体制の構築 |
下記のとおり、それぞれの推奨事項について詳しく見ていきます。
多要素認証（MFA）
ルートユーザーと IAM ユーザーの両方で MFA を有効化することが推奨されています。
仮想 MFA デバイス（Authy、Google Authenticator、Microsoft Authenticator など）は無料で利用可能です。
まずはルートユーザーと特権ユーザーから始めて、理想的にはすべてのユーザーに MFA を適用します。
ユーザー体験への影響が懸念される場合は、Context-aware 認証（通常と異なるデバイスや場所からのアクセス時のみ MFA を要求）という妥協点もあります。
＜補足＞
MFA は「やって当たり前」と思われがちですが、組織規模が大きくなると「一部の開発用 IAM ユーザーに MFA が設定されていなかった」ということが発生します。
AWS Security Hub のコントロールで MFA 未設定のユーザーを検知する仕組みを入れておくと安心です。
そもそも IAM ユーザーを極力使わず、IAM Identity Center 経由のフェデレーションに寄せることも検討すべきです。
基本の脅威検出（Amazon GuardDuty）
Amazon GuardDuty は、ワンクリックで有効化できる脅威検出サービスです。
コマンド＆コントロールサーバーとの通信、偵察活動、権限昇格、異常な振る舞いなど、一般的な脅威を検出します。
重要な検出結果については Amazon SNS を通じたアラート設定が推奨されています。
30日間の無料トライアルがあるため、まずは試してみるハードルが低いサービスです。
＜補足＞
GuardDuty は脅威を「検出」するサービスであり、検出結果に対して「誰かが対応する」ことで初めて効果を発揮します。
有効化するだけでなく、検出結果の通知先と対応フローをあらかじめ決めておくことが重要です。
Security Hub と組み合わせることで、検出結果を一元的に管理できます。
パブリックアクセスのブロック
Amazon S3 のブロックパブリックアクセス（以下、BPA）機能を使い、S3 バケットへのパブリックアクセスをアカウントレベルでブロックします。
新規アカウントではデフォルトで有効化されていますが、古いアカウントでは確認が必要です。
S3 に加えて、Amazon Machine Image（以下、AMI）と Amazon EBS スナップショットのパブリックアクセスもブロックすることが推奨されています。
EC2 コンソールの「データ保護とセキュリティ」から設定可能です。
＜補足＞
S3 バケットの意図しない公開は、過去に世界的に多くのデータ漏洩インシデントを引き起こしています。
「静的ウェブサイトをホストしたい」など明確なユースケースがない限り、アカウントレベルで BPA を有効化し、SCP で解除を禁止するのがベストです。
AMI や EBS スナップショットの BPA は見落とされがちなため、あわせて確認しておきましょう。
重大なセキュリティ検出結果への対応
AWS Security Hub や Amazon GuardDuty が検出した重要度 CRITICAL および HIGH の検出結果に対して、迅速に対応する体制を整えることが推奨されています。
具体的には、検出結果の担当者を明確にし、対応の SLA（たとえば CRITICAL は24時間以内に着手）を定め、対応状況を追跡する仕組みを設けます。
＜補足＞
検出結果が出ても「誰が対応するのか」が決まっていなければ、そのまま放置されてしまいます。
クイックウィンの段階では完全な自動化は不要ですが、「CRITICAL が出たらこの人に通知する」「週次でHIGH以上の棚卸しをする」といった最低限のルールだけでも決めておくことが第一歩です。
本ブログで触れなかったクイックウィン
下記の推奨事項は本シリーズの4カテゴリには含まれませんが、クイックウィンとして重要な項目です。
| カテゴリ | 推奨事項 | 概要 |
|---|---|---|
| セキュリティガバナンス | セキュリティ連絡先の割当て | AWS からのセキュリティ通知を確実に受け取るための連絡先設定 |
| セキュリティガバナンス | リージョンの選択と無効化 | SCP で未使用リージョンを無効化し、攻撃対象を限定する |
| セキュリティ保証 | クラウドセキュリティポスチャ管理 | AWS Security Hub によるベストプラクティスへの自動チェック |
| アイデンティティとアクセス管理 | ルートの保護 | ルートユーザーのアクセスキー削除と日常利用の禁止 |
| アイデンティティとアクセス管理 | ID フェデレーション | IAM Identity Center による一元的なアクセス管理 |
| アイデンティティとアクセス管理 | 意図しないアクセス権限の削除 | IAM Access Analyzer による外部アクセスの検出 |
| 脅威検知 | API 呼び出し監査 | AWS CloudTrail による API コールの記録 |
| 脅威検知 | 請求アラーム | 予期しないコスト増を早期検知する |
| インフラストラクチャ保護 | 危険な通信ポートのブロック | セキュリティグループの不要なインバウンドルール削除 |
| データ保護 | データセキュリティポスチャの分析 | Amazon Macie による機密データの検出 |
| アプリケーションセキュリティ | WAF とマネージドルールの活用 | AWS WAF によるウェブアプリケーション保護 |
| レジリエンス | レジリエンスの評価 | AWS Resilience Hub によるアプリケーションの回復力評価 |
詳細は AWS セキュリティ成熟度モデル - クイックウィン を参照してください。
まとめ
- AWS セキュリティ成熟度モデルは「何を先にやるべきか」の優先順位付けを支援するガイダンス
- クイックウィンは1〜2週間で実施可能な、コスト効率の高い改善策で構成
- まずは MFA の有効化、GuardDuty の有効化、パブリックアクセスのブロック、検出結果への対応体制づくりから着手するのが効果的
- 「有効化して終わり」ではなく、検出結果への対応フローの事前決定が重要
- 無料または低コストで始められるものが多く、コスト面のハードルは低い
次回は「基礎」フェーズを取り上げます。同じ4カテゴリで、クイックウィンの次に取り組むべき推奨事項がどう進化するかを紹介していきます。
この記事は私が書きました
髙井 大暉
記事一覧頑張ってインフラエンジニアやってます。
