- 公開日
- 最終更新日
【AWS セキュリティ成熟度モデルを読み解く】 - 基礎
この記事を共有する
目次
パーソル＆サーバーワークスの髙井です。
AWS を中心としたクラウドインフラの設計・構築・運用を担当しています。
はじめに
本ブログは「AWS セキュリティ成熟度モデルを読み解く」シリーズの第2回です。
前回の第1回ではクイックウィン（1〜2週間で実施可能な改善策）を紹介しました。今回取り上げる「基礎」フェーズは、クイックウィンよりも実装に多少の労力がかかるものの、組織のセキュリティ体制を本格的に固めるために欠かせない推奨事項で構成されています。
クイックウィンが「まず鍵をかける」だとすれば、基礎は「家の構造そのものを堅牢にする」フェーズです。
想定読者 - クイックウィンは一通り対応済みで、次のステップを検討している方 - マルチアカウント戦略や暗号化、インシデント対応の仕組みづくりに関心がある方
基礎フェーズの全体像
基礎フェーズでは、クイックウィンと同じ10カテゴリにわたり、より本格的な推奨事項が定義されています。本シリーズでは第1回と同じ4カテゴリ（アイデンティティとアクセス管理、脅威検知、データ保護、インシデントレスポンス）に絞って紹介します。
選定理由は第1回で述べたとおり、規模・業種を問わず多くの組織に当てはまる（汎用性が高い）カテゴリであるためです。
本ブログで取り上げる基礎の推奨事項一覧
| カテゴリ | 推奨事項 | 概要 |
|---|---|---|
| アイデンティティとアクセス管理 | 組織のアクセス許可ガードレール（SCP/RCP） | 組織全体で「やってはいけないこと」を強制的に制限する |
| 脅威検知 | 高度な脅威検出 | GuardDuty の追加保護プランで検知範囲を拡張する |
| データ保護 | 保存時のデータ暗号化（AWS KMS） | すべての重要データをお客様管理キーで暗号化する |
| インシデントレスポンス | インシデント対応プレイブック | インシデント発生時の行動計画を事前に文書化する |
下記のとおり、それぞれの推奨事項について詳しく見ていきます。
組織のアクセス許可ガードレール（SCP/RCP）
AWS Organizations のサービスコントロールポリシー（以下、SCP）を使用して、組織全体で「絶対にやってはいけないこと」を強制的に制限します。
SCP は権限を付与するものではなく、IAM で付与できる権限の上限を制限するものです。
たとえば下記のようなルールを設定できます。
- メンバーアカウントの組織からの離脱防止
- 本番環境以外でのGPU インスタンスの起動防止
- メンバーアカウントでのルートユーザーの使用防止
- 利用しないリージョンでのリソース作成防止
さらに、新しく追加されたリソースコントロールポリシー（以下、RCP）を使えば、リソース中心の制御も可能になります。
SCP がアイデンティティ側の制御であるのに対し、RCP はリソース側から「どのアイデンティティがアクセスできるか」を制限します。
SCP も RCP も無料で利用可能です。
＜補足＞
SCP は「セキュリティの不変条件」を定義するのに最適な仕組みです。
一度設定すれば頻繁に変更する必要がなく、組織内の全アカウントに一貫したガードレールを敷けます。
「管理アカウントには SCP が適用されない」という点は見落とされがちなため、管理アカウントにはワークロードを置かないことが前提です。
AWS 公式の SCP サンプル集が GitHub に公開されているため、まずはそこから自組織に合うものを選んで適用するのが現実的な進め方だと考えます。
高度な脅威検出
クイックウィンで有効化した Amazon GuardDuty の追加保護プランを有効化し、検知範囲を拡張します。
基礎フェーズでは下記のような保護プランの有効化が推奨されています。
- S3 Protection -- S3 バケットへの不審なアクセスパターンを検出
- EKS Protection -- Amazon EKS クラスター上の脅威を検出
- Lambda Protection -- Lambda 関数を悪用した攻撃を検出
- Malware Protection -- EC2 や EBS に対するマルウェアスキャン
また、GuardDuty の検出結果を AWS Security Hub に集約し、組織全体で一元的に管理する構成が推奨されています。
＜補足＞
クイックウィンで GuardDuty を有効化した段階では、基本的な脅威（VPC Flow Logs、DNS ログ、CloudTrail ベース）だけが検知対象です。
基礎フェーズで追加保護プランを有効化することで「見えていなかった脅威」が見えるようになります。
追加保護プランはそれぞれ料金が発生しますが、30日間の無料トライアルで実際のコスト感を把握できるため、まずは試してみることをおすすめします。
保存時のデータ暗号化（AWS KMS）
AWS に保存するすべての重要なデータを暗号化することが推奨されています。
AWS のサーバーサイド暗号化は、お客様の手間を最小限に抑えつつデータを保護できます。
特に機密データについては、AWS マネージドキーではなくお客様管理のキー（CMK）を使用することが推奨されます。
お客様管理のキーを使用するメリットは下記のとおりです。
- キーの無効化や削除を自分で管理できる
- アカウント間でキーを共有できる（インシデント対応時のスナップショット共有などに便利）
- コンプライアンス要件に応じてローテーション間隔をカスタマイズできる
＜補足＞
「暗号化はコストがかかる」と思われがちですが、AWS KMS の料金はリクエスト20,000件/月まで無料枠があり、それ以降もチェック1回あたり数セントです。
暗号化しない理由がないレベルのコスト感だと考えています。
注意すべきは、暗号化を後から適用する場合に一部のリソース（EBS ボリュームなど）はスナップショットを経由して再作成が必要になる点です。
新規リソースはデフォルト暗号化を有効にしておくのがベストです。
インシデント対応プレイブック
インシデント対応の第一歩は、望ましくない状況をすべて想定し、それぞれの行動計画を定義することです。
たとえば Amazon GuardDuty が EC2 インスタンスから外部の不審なサーバーへの大量通信を検出した場合、「セキュリティグループを変更して全てのアウトバウンド接続を禁止し、インシデント調査チーム用のリモートアクセスのみ許可する」といった具体的な手順を事前に文書化しておきます。
文書化された計画のメリットは下記のとおりです。
- 最も経験豊富なメンバーが不在でも、一貫した対応が可能になる
- 対応の属人化を防ぎ、スケーラビリティが確保される
- 事後の振り返りで計画の妥当性を検証できる
AWS は日本語のプレイブックサンプルを GitHub 上で公開しています。
＜補足＞
プレイブックは「作ること」よりも「使える状態に維持すること」が難しいです。
作っただけで棚に置いておくと、いざというときに担当者が存在を知らなかったり、手順が古くなっていたりします。
定期的な机上演習（効率化フェーズで詳しく触れます）と組み合わせて、プレイブックを「生きたドキュメント」にすることが大切です。
本ブログで触れなかった基礎の推奨事項
下記の推奨事項は本シリーズの4カテゴリには含まれませんが、基礎フェーズとして重要な項目です。
| カテゴリ | 推奨事項 | 概要 |
|---|---|---|
| セキュリティガバナンス | コンプライアンスと規制要件の特定 | 自組織に適用される規制やフレームワークを整理する |
| セキュリティガバナンス | セキュリティ研修計画 | エンジニア向けセキュリティトレーニングの策定と実施 |
| セキュリティ保証 | インベントリと設定モニタリング | AWS Config によるリソースの設定変更追跡 |
| アイデンティティとアクセス管理 | 一時的な認証情報の使用 | IAM Role とインスタンスプロファイルの活用 |
| アイデンティティとアクセス管理 | IMDSv2 | EC2 メタデータサービスの v2 への移行 |
| 脆弱性管理 | インフラの脆弱性管理 | Amazon Inspector による OS・パッケージの脆弱性スキャン |
| 脆弱性管理 | アプリケーションの脆弱性管理 | SAST/DAST ツールによるコードレベルの脆弱性検出 |
| インフラストラクチャ保護 | ネットワークアクセスの制限 | セキュリティグループの最小権限化 |
| インフラストラクチャ保護 | EC2 インスタンスの安全な管理 | AWS Systems Manager Fleet Manager による SSHレスな管理 |
| インフラストラクチャ保護 | ネットワークのセグメント化 | VPC の分離と通信制御 |
| インフラストラクチャ保護 | マルチアカウント管理 | AWS Control Tower によるランディングゾーンの構築 |
| データ保護 | データのバックアップ | AWS Backup による定期バックアップ |
| データ保護 | 機密データの検出 | Amazon Macie による機密情報の特定 |
| アプリケーションセキュリティ | セキュリティチームの関与 | 開発プロセスへのセキュリティレビューの組み込み |
| アプリケーションセキュリティ | コード内のシークレット管理 | Secrets Manager による認証情報の安全な管理 |
| レジリエンス | マルチ AZ による可用性向上 | 複数のアベイラビリティーゾーンへの分散配置 |
詳細は AWS セキュリティ成熟度モデル - 基礎 を参照してください。
まとめ
- 基礎フェーズはクイックウィンより労力がかかるが、組織のセキュリティ体制を根本から強化するための推奨事項
- SCP/RCP によるガードレールは「組織として絶対にやってはいけないこと」を強制する仕組みとして非常に有効
- GuardDuty の追加保護プランによる検知範囲の拡張で、「見えていなかった脅威」の可視化
- 暗号化はコスト面のハードルが低く、「やらない理由がない」対策
- インシデント対応プレイブックは作って終わりではなく、定期的な検証と維持が重要
次回は「効率化」フェーズを取り上げます。同じ4カテゴリで、セキュリティ運用を仕組み化・自動化していくための推奨事項を紹介します。
この記事は私が書きました
髙井 大暉
記事一覧頑張ってインフラエンジニアやってます。
