- 公開日
- 最終更新日
【AWS セキュリティ成熟度モデルを読み解く】 - 効率化
この記事を共有する
目次
パーソル＆サーバーワークスの髙井です。
AWS を中心としたクラウドインフラの設計・構築・運用を担当しています。
はじめに
本ブログは「AWS セキュリティ成熟度モデルを読み解く」シリーズの第3回です。
前回の第2回では基礎フェーズ（組織のセキュリティ体制を本格的に固めるための推奨事項）を紹介しました。今回取り上げる「効率化」フェーズは、これまでに整備したセキュリティ対策を仕組み化・自動化し、運用負荷を下げながらセキュリティレベルを維持・向上させることを目的としています。
クイックウィンが「鍵をかける」、基礎が「家の構造を堅牢にする」だとすれば、効率化は「セキュリティシステムを自動運転にする」フェーズです。
想定読者
- 基礎フェーズまでの対策は概ね整備済みで、運用の効率化・自動化を検討している方
- 最小権限の維持、SIEM 基盤の構築、インシデント対応の自動化に関心がある方
効率化フェーズの全体像
効率化フェーズでは、クイックウィンや基礎と同じ10カテゴリにわたり、運用の仕組み化・自動化に焦点を当てた推奨事項が定義されています。本シリーズでは第1回と同じ4カテゴリ（アイデンティティとアクセス管理、脅威検知、データ保護、インシデントレスポンス）に絞って紹介します。
選定理由は第1回で述べたとおり、規模・業種を問わず多くの組織に当てはまる（汎用性が高い）カテゴリであるためです。
本ブログで取り上げる効率化の推奨事項一覧
| カテゴリ | 推奨事項 | 概要 |
|---|---|---|
| アイデンティティとアクセス管理 | 最小権限の見直し | 未使用の権限を特定・削除し、最小権限を維持し続ける |
| 脅威検知 | カスタム脅威検出（SIEM/SecLake） | 組織固有の脅威を検出するためのカスタムルール・分析基盤を構築する |
| データ保護 | 通信の暗号化 | 転送中のデータを TLS で暗号化し、証明書管理を自動化する |
| インシデントレスポンス | 重要なプレイブックの自動化 | 頻度の高いインシデント対応を自動化して対応速度を向上させる |
下記のとおり、それぞれの推奨事項について詳しく見ていきます。
最小権限の見直し
基礎フェーズまでに IAM ポリシーを設計・適用していても、時間の経過とともに「使われていない権限」が蓄積されていきます。
効率化フェーズでは、IAM Access Analyzer の未使用アクセス分析機能を活用し、定期的に権限の棚卸しを行うことが推奨されています。
IAM Access Analyzer は下記の情報を提供します。
- 一定期間使用されていない IAM ロール・ユーザーの特定
- 付与されているが一度も使われていないアクション・サービスの特定
- 実際のアクセスパターンに基づくポリシーの推奨
これらの情報をもとに、不要な権限を削除し、最小権限を継続的に維持する運用サイクルを構築します。
＜補足＞
最小権限を「最初から完璧に設計する」のは現実的ではありません。
「広めに付与→実績ベースで絞る」というサイクルを回し続けることが、最小権限を維持する最も現実的なアプローチです。
IAM Access Analyzer の未使用アクセス分析は Organization レベルで有効化でき、全アカウントの権限状況を一元的に把握できるため、マルチアカウント環境では特に有用です。
カスタム脅威検出
GuardDuty は汎用的な脅威を検出するサービスですが、組織固有のビジネスロジックに基づく異常は検知できません。
効率化フェーズでは、Amazon Security Lake にセキュリティログを一元集約し、Amazon Athena や Amazon OpenSearch Service で独自の分析・検知ルールを構築することが推奨されています。
カスタム脅威検出の構成例は下記のとおりです。
- Amazon Security Lake でログを OCSF 形式に正規化して一元管理
- Amazon Athena によるアドホックな脅威ハンティングクエリの実行
- Amazon OpenSearch Service によるリアルタイムのダッシュボード・アラート構築
- 組織固有のルール（特定の時間帯の管理操作、通常とは異なるデータ転送パターンなど）の定義
＜補足＞
GuardDuty だけでは組織固有の異常（たとえば「営業時間外に特定の S3 バケットから大量ダウンロードが発生した」など）は検知できません。
Security Lake を中心とした分析基盤の構築は投資が必要ですが、組織のセキュリティ運用を「受動的な検知」から「能動的な脅威ハンティング」へ進化させるために欠かせないステップです。
通信の暗号化
基礎フェーズでは保存時の暗号化を取り上げましたが、効率化フェーズでは転送中のデータの暗号化が推奨されています。
AWS Certificate Manager（以下、ACM）を使用して TLS 証明書を自動管理し、すべての通信経路で暗号化を適用します。
推奨される対策は下記のとおりです。
- 外部向け通信（ALB、CloudFront、API Gateway）への TLS 適用
- 内部通信（内部 ALB、サービス間通信）への TLS 適用
- ACM による証明書の自動更新（手動更新の運用負荷を排除）
- HTTP から HTTPS へのリダイレクト設定
＜補足＞
ACM で発行する証明書は無料なため、内部 ALB にも TLS を適用するコストは実質ゼロです。
「内部通信だから暗号化は不要」という考え方はゼロトラストの観点からも推奨されません。
ACM と ALB/CloudFront の組み合わせであれば証明書の更新も自動化されるため、運用負荷もほとんど発生しません。
重要なプレイブックの自動化
基礎フェーズで作成したインシデント対応プレイブックのうち、頻度が高く手順が定型化されたものを自動化します。
AWS Lambda や AWS Systems Manager Automation を活用し、検出から初動対応までの時間を大幅に短縮します。
自動化の候補となるアクションの例は下記のとおりです。
- GuardDuty が不正な EC2 通信を検知した場合 → セキュリティグループを即座に隔離用に変更
- IAM アクセスキーの漏洩が検知された場合 → 対象キーを自動無効化
- S3 バケットのパブリックアクセスが有効化された場合 → 自動で BPA を再適用
- Security Hub で CRITICAL の検出結果が発生した場合 → Slack/Teams への即座通知
EventBridge ルールをトリガーとして Lambda 関数を実行する構成が一般的です。
＜補足＞
自動化は強力ですが、誤検知による意図しない隔離や無効化のリスクも伴います。
段階的に自動化を進めることが安全です。
まずは「通知の自動化」から始め、実績が十分に積み上がった対応から「アクションの自動化」に移行するアプローチが推奨されます。
本番環境への自動アクションは、十分なテストと承認フローを経てから導入すべきです。
本ブログで触れなかった効率化の推奨事項
下記の推奨事項は本シリーズの4カテゴリには含まれませんが、効率化フェーズとして重要な項目です。
| カテゴリ | 推奨事項 | 概要 |
|---|---|---|
| セキュリティガバナンス | セキュアなアーキテクチャ設計 | セキュリティを設計段階から組み込むアプローチの採用 |
| セキュリティガバナンス | Infrastructure as Code の活用 | インフラ構成のコード化によるセキュリティ設定の再現性確保 |
| セキュリティガバナンス | タグ付け戦略 | リソースのタグ付けによるセキュリティ管理の効率化 |
| セキュリティ保証 | コンプライアンスレポートの作成 | AWS Audit Manager によるコンプライアンス証跡の自動収集 |
| アイデンティティとアクセス管理 | 顧客 ID とアクセス管理（CIAM） | Amazon Cognito による顧客向け認証基盤の構築 |
| 脆弱性管理 | セキュリティチャンピオンの配置 | 開発チーム内にセキュリティ推進役を設置 |
| 脆弱性管理 | DevSecOps とパイプライン | CI/CD パイプラインへのセキュリティテストの組み込み |
| インフラストラクチャ保護 | ゴールデンイメージパイプライン | EC2 Image Builder によるセキュアな AMI の自動構築 |
| インフラストラクチャ保護 | マルウェア対策 | Amazon GuardDuty Malware Protection によるスキャン自動化 |
| インフラストラクチャ保護 | アウトバウンド通信の制御 | VPC エンドポイントや NAT Gateway によるアウトバウンド制御 |
| アプリケーションセキュリティ | 脅威モデリングの実施 | 設計段階での脅威の特定とリスク評価 |
| アプリケーションセキュリティ | WAF とカスタムルール | AWS WAF のカスタムルールによるアプリケーション固有の防御 |
| アプリケーションセキュリティ | DDoS 攻撃の緩和 | AWS Shield Advanced による高度な DDoS 防御 |
| インシデントレスポンス | インシデント机上演習の実施 | 定期的なシミュレーションによるプレイブックの検証と改善 |
| インシデントレスポンス | セキュリティ調査と原因分析 | Amazon Detective による検出結果の深掘り調査 |
| レジリエンス | ディザスタリカバリプラン | 災害発生時の復旧手順と RTO/RPO の定義 |
詳細は AWS セキュリティ成熟度モデル - 効率化 を参照してください。
まとめ
- 効率化フェーズはセキュリティ対策を「仕組み化・自動化」し、運用負荷を下げながらセキュリティレベルを維持するフェーズ
- IAM Access Analyzer による権限棚卸しの定期実行で、最小権限を継続的に維持
- Security Lake を中心とした分析基盤により、組織固有の脅威を能動的に検出
- ACM による証明書管理の自動化で、転送中のデータ暗号化を運用負荷なく実現
- インシデント対応の自動化は「通知→アクション」の段階的な拡大が安全
次回は「最適化」フェーズを取り上げます。同じ4カテゴリで、成熟した組織がさらに高度な対策を講じるための推奨事項を紹介します。
この記事は私が書きました
髙井 大暉
記事一覧頑張ってインフラエンジニアやってます。
