Open18
AWS W-A「セキュリティの柱」
ピン留めされたアイテム
issyissy作成中！
- セキュリティの基礎
- IDおよびアクセス管理
- 検知
- インフラストラクチャ保護
- データ保護
- インシデント対応
- アプリケーションのセキュリティ
issyissy設計原則
-
強力なアイデンティティ基盤を実装する
- 最小権限の原則を実装
- 適切な認可による役割分担
- ID管理の一元化
- 長期的な認証情報の使用回避
-
トレーサビリティの維持
- リアルタイムのモニタリング、アラート、監査
- ログとメトリクスの自動収集と分析
-
すべてのレイヤーでセキュリティを適用する
- 深層防御アプローチの適用
- すべてのレイヤー（ネットワーク、VPC、インスタンス、OS、アプリケーション等）でのセキュリティ実装
-
セキュリティのベストプラクティスを自動化する
- 自動化されたセキュリティメカニズムの導入
- コードとしてのセキュリティ管理（Infrastructure as Code）
-
伝送中および保管中のデータを保護する
- 伝送中および保管中のデータの暗号化
- データの分類と適切な保護メカニズムの使用
-
データに人の手を入れない
- 自動化ツールの活用によるヒューマンエラーリスクの軽減
- 機密データへの直接アクセス削減
-
セキュリティイベントに備える
- インシデント管理・調査ポリシーの確立
- インシデント対応シミュレーションの実施
- 自動化ツールによる迅速な検出、調査、復旧
issyissyセキュリティの基礎: AWS アカウントの管理と分離
推奨事項
- ワークロードを個別アカウントで整理
- 機能、コンプライアンス要件、共通のコントロールセットに基づいてアカウントをグループ化
- 開発/テスト環境と本番環境をアカウントレベルで分離
アカウントの一元管理
-
AWS Organizations の活用
- アカウントの作成と管理の自動化
- 組織単位（OU）によるアカウントのグループ化
- ルートユーザーのEメールアドレス設定に注意
制御の一括設定
- サービスコントロールポリシー（SCP）の使用
- 組織レベル、OU レベル、アカウントレベルでの適用
- 特定のサービス、リージョン、アクションの制限
-
AWS Control Tower の活用
- 複数アカウントの効率的な設定と管理
- アカウント設定の自動化
- ガードレールの適用
- ダッシュボードによる可視化
サービスとリソースの一括設定
- AWS CloudTrail による中央ログ記録
- AWS Config によるコンプライアンス監査
- AWS CloudFormation StackSets による複数アカウント管理
セキュリティサービスの委任管理
- 管理アカウントと請求アカウントの分離
- GuardDuty、Security Hub、AWS Config 等のサービスでの AWS Organizations との統合
issySEC01-BP01 アカウントを使用してワークロードを分ける
ベストプラクティスが確立されていない場合のリスクレベル
高
概要
マルチアカウント戦略を採用し、環境とワークロード間に共通ガードレールを設定して分離を確立する。
期待される成果
クラウドオペレーション、無関係のワークロード、環境を別々のアカウントに分類し、セキュリティを向上させるアカウント構造。
一般的なアンチパターン
- データ重要度の異なるワークロードを同一アカウントに配置
- 不明確な組織単位（OU）構造
メリット
- 誤アクセスの影響範囲限定
- アクセスの一元的ガバナンス
- セキュリティの一元管理
- アカウント管理の自動化
- コンプライアンス対応の集中監査
実装ガイダンス
-
マルチアカウント戦略
- セキュリティ分離境界
- 「Organizing Your AWS Environment Using Multiple Accounts」 (複数のアカウントを使用した AWS 環境の組織化) を参照
実装手順
-
組織単位構造の設計
- ビジネスニーズ、データ重要度、ワークロード構造に合わせる
-
ランディングゾーンの作成
- AWS Control Tower または カスタムビルドを使用
-
ガードレールの確立
- AWS Control Tower の必須・オプションコントロールを活用
-
新リージョンアクセスの制限
- IAMリソースの伝播を制御
-
AWS CloudFormation StackSets の検討
- 複数アカウント・リージョンへのリソースデプロイを簡素化
実装ツール
- AWS Organizations: アカウントの階層化管理
- AWS Control Tower: ランディングゾーン自動設定
- サービスコントロールポリシー（SCP）: きめ細やかな予防的コントロール
- AWS Config: 積極的・検出的コントロール
issySEC01-BP02 セキュアアカウントのルートユーザーおよびプロパティ
ベストプラクティスが確立されていない場合のリスクレベル
高
概要
ルートユーザーは最高権限を持つため、適切な管理と制限が不可欠。ルートユーザーの使用を最小限に抑え、強力な認証と監視を実施する。
期待される成果
ルートユーザー認証情報の不正使用による偶発的または意図的な損害のリスク低減。
一般的なアンチパターン
- 日常的なタスクでのルートユーザーの使用
- 緊急時対応計画の定期的なテスト不足
- 代替アカウント回復方法の考慮・テスト不足
- DNS、Eメール、携帯電話会社のセキュリティ境界としての扱い不足
メリット
アカウントでのアクションのコントロールと監査の向上
実装ガイダンス
推奨事項は CIS AWS Foundations ベンチマークバージョン 1.4.0
AWS ベストプラクティスガイドラインも参照
-
予防的コントロール
- 正確な連絡先情報の設定
- ルートユーザーのアクセスキー作成禁止
- 多要素認証(MFA)の有効化
- 複雑なパスワードの使用
-
検出コントロール
- ルート認証情報使用の検出アラーム作成
- Amazon GuardDutyの有効化
-
運用ガイダンス
- ルートユーザー認証情報へのアクセス担当者の決定
- ルートユーザーの例外的使用
- 定期的なアクセスチェックと手順テスト
- インシデント対応手順の準備
実装ツール
- AWS Organizations
- AWS Identity and Access Management (IAM)
- Amazon GuardDuty
- AWS Config
- AWS Control Tower
issyセキュリティの基礎: ワークロードを安全に運用する
概要
ワークロードのライフサイクル全体を通じて安全な運用を確保し、組織的なガバナンスアプローチを採用する。
ポイント
-
ガバナンスの重要性
- 一貫した意思決定を導くプロセス
- ワークロードの管理目標達成を確認する方法
-
包括的なセキュリティ実践
- 組織レベルとワークロードレベルでのベストプラクティス適用
- 脅威モデルと管理目標の継続的な更新
-
オートメーションの活用
- プロセスの一貫性と再現性の確保
- デプロイの信頼性向上とリスク軽減
-
テストと検証
- 非運用環境での事前テスト
- 早期フィードバックによる再作業の削減
-
共通機能と共有コンポーネントの利用
- 複数チームで利用可能なサービスの提供
- ビルダーのワークロードサイクル時間改善
メリット
- デプロイの加速
- 組織全体のセキュリティ機能の向上
- 一貫したセキュリティ管理目標の達成
- 管理態勢とリスクポジションの適切な報告
実装のポイント
- セキュリティプロセスの自動化
- コードによる設定変更
- 共通サービス（アカウント作成、ID管理、ログ設定等）の確立
issyissyID およびアクセス管理: ID 管理
概要
適切なユーザーが適切な条件下で適切なリソースにアクセスできるように、堅牢なアイデンティティ管理とアクセス許可が必要です。
管理するIDの２つのタイプ
- 人的ID
- 管理者、開発者、運用者などの人が使用するもの
- マシンID
- ワークロードアプリケーションや運用ツールなどが使用するもの
- EC2やLambdaなど
ベストプラクティス
- SEC02-BP01 強力なサインインメカニズムを使用する
- 望ましい結果
- IAMユーザーのパスワードポリシーを強化
- MFAの利用を強制
- CloudTrailなどでログインを監視
- アンチパターン
- 強力なパスワードポリシーを適用しない、MFAを使用しない
- 同一IDを共有
- 疑わしいサインイン試行を検知していない
- 望ましい結果
- SEC02-BP02 一時的な認証情報を使用する
- 望ましい結果
- EC2インスタンスに対するIAMロールやLambdaの実行ロールなど
- アンチパターン
- 長期的にアクセスキーを使用してCLIを実行
- コードにアクセスキーを埋め込んでパブリックなGitリポジトリにアップロード
- モバイルアプリにアクセスキーを埋め込んでアプリストアに公開
- アクセスキーを共有、退職者のアクセスキーを放置
- EC2などにアクセスキーを格納
- 望ましい結果
- SEC02-BP03 シークレットを安全に保存して使用する
- 望ましい結果
- Secrets Managerで認証情報を管理、ローテーション
- Systems ManagerまたはEC2 Instance Connect使用してEC2に接続する
- CodeGuruでコードスキャン
- git-secretsを使ってシークレットがコミットされるのを防止
- アンチパターン
- 認証情報をローテーションしない
- コードや設定ファイルに保管
- 認証情報を暗号化していない
- 望ましい結果
- SEC02-BP04 一元化された ID プロバイダーに依存する
- 望ましい結果
- Cognito
- AWS Organizations
- AWS IAM Identity Center
- アンチパターン
- 複数のアプリケーションやシステムで個別にユーザー管理
- 人事異動とID管理が自動連携しておらず手動でのメンテナンス
- 望ましい結果
- SEC02-BP05 認証情報を定期的に監査してローテーションする
- 望ましい結果
- アンチパターン
- 認証情報の監査を行わない
- 未使用の認証情報
- 定期的にローテーションしていない
- SEC02-BP06 ユーザーグループと属性を採用する
- 望ましい結果
- 認証情報レポートを確認する
- AWS Config ルール、AWS Security Hub セキュリティ標準、Amazon GuardDutyを使用する
- Secrets Managerで認証情報を管理、ローテーション
- アンチパターン
- ユーザーごとに権限管理していて、複数ユーザーで重複している
- グループ定義が広いため最小権限になっていない
- グループ定義が細かすぎて利便性が損なわれている
- リソースに対するアクセス許可が複数のグループで重複している
- 標準的なIDプロバイダーで管理を行っていない
- 望ましい結果
issyID およびアクセス管理: アクセス許可の管理
管理方法
権限は使用する用途で明確に管理する。そうすることで「誰がどのような条件で何にアクセスできるか」を明確にすることができる。
最小特権の原則を意識するようにします。
ポリシーの定義方法はマネージドポリシーと、インラインポリシーの２つがあります。マネージドポリシーを使用することを推奨します。
- マネージドポリシー
- AWS管理ポリシー
- AWSによって作成管理されるもの
- カスタマー管理ポリシー
- ユーザーがユースケースに合わせて自由に定義したもの
- 定義することで流用できる
- AWS管理ポリシー
- インラインポリシー
- 単一のユーザー、グループ、ロールに直接追加するもの
- 記述したところでしか使えない
以下も参照する
- リソースベースのポリシー
- アクセス許可の境界（Permissions boundary）
- 属性ベースのアクセスコントロール（ABAC）
- AWS Organizationsのサービスコントロールポリシー（SCP）
ベストプラクティス
- SEC03-BP01 アクセス要件を定義する
- 望ましい結果
- Secrets ManagerやSystems Manager Parameter Store
- 一時的な認証情報
- アクセスキーが最後に使用された情報をもとに、ローテーションまたは無効化、削除
- アンチパターン
- シークレットのハードコーディング
- ユーザーごとにカスタムのアクセス許可
- 永続的な認証情報
- 望ましい結果
- SEC03-BP02 最小権限アクセスを付与する
- 望ましい結果
- 最小特権の原則に従う
- IAMポリシーで条件キーを使う
- ルートユーザーを使用しない
- 定期的なアクセス許可の見直し
- アンチパターン
- 全員管理者権限
- ルートユーザーを日常的に使用
- 定期的なアクセス許可の見直しを行わない
- 望ましい結果
- SEC03-BP03 緊急アクセスプロセスを確立する
- 望ましい結果
- 緊急アクセスのプロセスを文書化し、テストする
- 緊急アクセス用のアカウント（緊急アクセス経路(Breakglass)）からIAMロールの切り替えでアクセスできるようにする
- 緊急アクセス用に各AWSアカウント内にIAMユーザーを作成しておき直接ログイン
- 緊急アクセス時にルートユーザーを使用する
- アンチパターン
- 緊急アクセスの備えがない、テストが不十分
- 緊急アクセスのプロセスが日常的に利用可能
- 緊急アクセスの監査ログがない
- 望ましい結果
- SEC03-BP04 アクセス許可を継続的に減らす
- 望ましい結果
- 最小特権の原則
- IAM Access Analyzer
- 未使用ポリシーを確認する
- アンチパターン
- 全員管理者アクセス
- 必要以上に広い権限を設定している
- 不要なアクセス許可を放置
- 望ましい結果
- SEC03-BP05 組織のアクセス許可ガードレールを定義する
- 望ましい結果
- SCPsで権限をAWSアカウントに対するガバナンスを適用する
- リソースベースポリシーを使う（S3バケットポリシー）
- ワークロードでアカウントを分離
- 明示的に拒否する（Deny）
- 暗黙的な拒否（Deny）だといつかAllowされてしまう可能性
- アンチパターン
- AWS Organizationでメンバーアカウントの制限をしていない
- ガードレールを設定していない
- 複数のワークロードを１つのAWSアカウントで運用し、タグなどのポリシーに依存して制御している
- 暗黙的な拒否（Deny）に依存している
- 望ましい結果
- SEC03-BP06 ライフサイクルに基づいてアクセスを管理する
- 望ましい結果
- 最小特権の原則
- 未使用のIDの棚卸
- ID管理のライフサイクルの自動化
- アンチパターン
- 過剰なアクセス許可を付与
- 役割が変わってもアクセス許可を見直ししない
- 未使用のIDに権限を付与したまま
- ID管理のライフサイクルが自動化されていない
- 望ましい結果
- SEC03-BP07 パブリックアクセスとクロスアカウントアクセスを分析する
- 望ましい結果
- 共有リソースに対するアクセスをモニタリングする
- 共有されたことを把握、管理する
- IAM Access Analyzer
- IAMポリシーの条件キー
- AWS Config
- Security Hub
- CloudWatchによるアラート
- アンチパターン
- 共有リソースへのアクセスを取得しない
- リソースへのクロスアカウントまたはパブリックアクセスを実施する前に承認などを行わない
- S3のバケットポリシーなど
- 望ましい結果
- SEC03-BP08 組織内でリソースを安全に共有する
- 望ましい結果
- SCPs
- AWS Config
- Security Hub
- 共有されたことを把握、管理する
- IAM Access Analyzer
- IAMポリシーの条件キー
- アンチパターン
- 継続的にモニタリングせず、外部共有に対するアラートがない
- 共有するしないの基準がない
- 必要以上のアクセス許可をしている
- 手動で作成する
- 望ましい結果
- SEC03-BP09 リソースをサードパーティーと安全に共有する
- ※SaaSを使用する場合
- 望ましい結果
- IAM信頼ポリシーで外部IDを使用する
- 最小特権の原則
- IAMポリシーの条件キー
- アンチパターン
- 条件なしで信頼ポリシーを使用
- 長期的なアクセスキーを使用
- IDの再利用
issyissy概要
主要な２つの検出領域について
- 予期しない・望ましくない設定変更の検知
- Infrastructure as Code(IaC)とCI/CDパイプラインを活用した事前チェック
- 本番/非本番環境へのデプロイ時のチェック（AWS標準ツール、オープンソース、パートナーツール）
- 運用中のアプリケーションにおける予期しない設定変更の監視
- 想定外動作の検知
- Amazon GuardDutyによる不正/悪意のある活動の検知
- 異常なAPIコールの監視
- セキュリティ設定を変更するAPIコールの明示的なモニタリング
検出の重要性と実装について
- セキュリティライフサイクルの重要な構成要素として機能
- 品質管理、法的義務、コンプライアンス要件への対応をサポート
- ワークロードログの分析による脆弱性の特定
- 定期的な検出メカニズムの見直しによる要件充足の確認
- 自動化されたアラートと通知の設定による迅速な対応体制の確立
この検出の枠組みにより、組織は潜在的なセキュリティリスクを早期に特定し、適切な対応を取ることが可能になります。
issySEC04-BP01 サービスとアプリケーションのログ記録を設定する
ベストプラクティスを活用しない場合のリスクレベル
高
概要
セキュリティイベントログの保持は、監査、調査、運用における基本原則であり、GRC（ガバナンス、リスク、コンプライアンス）の要件を満たすために必要不可欠
期待される効果
- セキュリティイベントログの確実かつ一貫性のある取得
- タイムリーな情報アクセス
- ログの一元化による運用効率の向上
一般的なアンチパターン
- ログの不適切な保持期間設定（永久保存または即時削除）
- 無制限のログアクセス許可
- 手動プロセスへの過度な依存
- 無差別なログ収集
- ※ 基本はすべてのログを保存する。そのうえで、必要ないものを判断
- 必要時のみのログ整合性チェック
メリット
- セキュリティインシデントの根本原因分析（RCA）の実施が可能
- GRCの義務における証拠としての活用
実装ガイダンス
- インシデント調査に必要な関連ログの確実な保存
- 適切なクエリと取得メカニズムの実装
- アラート生成メカニズムの確立
実装手順
- ログソースの選択（CloudTrail、VPC フローログ、Route 53 Resolver等）
- ビジネスで必要なユースケースに基づいたものを選択する
- 適切なログストレージの選択（S3バケットまたはCloudWatch Logs）
- S3はライフサイクル
- CloudWatch Logs はCloudWatch Logs Insightsで効率的に分析できる
- 保持期間とライフサイクルポリシーの設定
- セキュリティ要件と、法令、規制等を考慮する
- 各種AWSサービスの個別ログ設定
- クエリメカニズムの実装
- CloudWatch Logs Insights
- Amazon S3 + Amazon Athena
- OpenSearch ServiceとSIEM→GitHub参照
- アラート機能の設定
- セキュリティサービスのアラート機能を利用
- AWS Config
- Amazon GuardDuty
- AWS Security Hub
- セキュリティサービスのアラート機能を利用
実装ツール
- AWS CloudTrail
- Amazon VPC フローログ
- Amazon Route 53 Resolver
- Amazon Security Lake
- Amazon S3
- Amazon CloudWatch
- AWS Config
- Amazon GuardDuty
- AWS Security Hub
- Amazon Athena
- Amazon OpenSearch Service
参考
issySEC04-BP02 標準化した場所にログ、検出結果、メトリクスを取り込む
ベストプラクティスを活用しない場合のリスクレベル
中
概要
セキュリティログ、検出結果、メトリクスを標準化された場所に集約し、効率的な分析と異常検知を可能にする取り組み
期待される効果
- セキュリティデータの標準化された収集・分析・可視化
- 複数システムからのデータの効率的な相関分析
- SIEMなどを活用したタイムリーな対応とエスカレーション
一般的なアンチパターン
- チーム個別のログ管理による組織戦略との不整合
- 不十分なアクセス制御
- データ分類ポリシーの無視
- データ主権・ローカリゼーション要件の軽視
メリット
- ログデータからの効果的なインサイト抽出
- 自動ライフサイクル管理によるコスト削減
- きめ細かなアクセス制御の実現
- データの相関分析と可視化の効率化
実装ガイダンス
- ログアーカイブアカウントへのセキュリティログの集約
- Amazon Security Lakeを活用したデータの標準化
- セキュリティログはデータソースによって形式が異なる。標準化しようとしている団体→OCSF（Open Cybersecurity Schema Framework）
- 参考：AWSドキュメント＞Security Lake でサイバーセキュリティスキーマフレームワーク (OCSF) を開く
- 参考：ITmedia NEWS >サイバー攻撃検知のためのオープンソースプロジェクト発足 AWSやゼロトラスト関連企業などがデータ連携効率化
- セキュリティツール用アカウントでの分析ツールの展開
- データ主権とコンプライアンス要件の考慮
実装手順
- ログアーカイブアカウントとセキュリティツール用アカウントの作成
- AWS Organizations を使用
- ログアーカイブ用と、分析などに利用する加工済みを完全に分離した場合など。要件に応じて検討
- セキュリティデータの標準化保存場所の設定
- データレイクアーキテクチャ
- データソースの公開設定
- ETL プロセスが必要な形式ではなく、データソースからエクスポート
- アクセスツールの設定と権限管理
- Amazon Athena、Amazon QuickSight、サードパーティーソリューション
実装ツール
- AWS Organizations
- AWS Control Tower
- Amazon Security Lake
- AWS Security Hub
- Amazon Athena
- Amazon QuickSight
- Amazon GuardDuty
- Amazon Inspector
issySEC04-BP03 セキュリティアラートを相関付けて充実させる
ベストプラクティスを活用しない場合のリスクレベル
低
概要
複数のソースから生成されるセキュリティアラートを自動的に相関付け・強化することで、インシデントの正確な特定と対応を実現する取り組み
期待される効果
- アラートデータの自動的な関連付けと強化
- イベントの重要度判断の精度向上
- 監視・調査チームの負担軽減
- インシデント対応の迅速化
一般的なアンチパターン
- 複数グループによる重複した調査作業
- 手動での相関付けとエンリッチメント作業
- 脅威検出システムの情報のみに依存した重要度判断
メリット
- 調査担当者の認知負担の軽減
- データ準備作業の自動化
- インシデント判断の迅速化
- 関連付けの手作業を軽減することで判断までの時間短縮
- イベントの重要度評価の精度向上
- 単独のイベントだけでなく複数イベントを組み合わせることで実際の重要度が評価できる
実装ガイダンス
- 複数のAWSセキュリティサービスからのアラート統合
- イベント管理 (SIEM) ツールと統合
- アイデンティティ、アクション、リソース間のマッピング作成
- Amazon Detectiveによるアラートの視覚的グラフ化
- コンテキストに基づいた重要度の動的調整
実装手順
- セキュリティアラート情報ソースの特定と分析
- アラート集約メカニズムの確立
- 相関付け・エンリッチメントソースの特定
- アラートとデータソースの統合による詳細なコンテキスト作成
実装ツール
- Amazon GuardDuty
- AWS Security Hub
- Amazon Detective
- Amazon EventBridge
- Amazon CloudWatch
- AWS Lambda
- Amazon Athena
- Amazon Security Lake
- Amazon OpenSearch Service
- AWS CloudTrail
参考
issySEC04-BP04 非準拠リソースの修復を開始する
ベストプラクティスを活用しない場合のリスクレベル
低
概要
非準拠リソースを検出した際のプログラムによる修復手順の定義と実行を通じて、迅速かつ一貫した対応を実現する取り組み
期待される効果
- 標準的な修復手順のプログラム化
- 手動または自動での修復実行
- 非準拠リソースの効率的な検知と通知
- 適切な監視と制御メカニズムの確立
一般的なアンチパターン
- 不十分なテストによる自動修復の実装
- 人間の介入メカニズムの欠如
- インシデント対応・復旧プログラムとの不統合
メリット
- 構成ミスへの迅速な対応
- 一貫した修復プロセスの実現
- 人為的ミスのリスク軽減
- 大規模環境での効率的な処理
実装ガイダンス
- AWS ConfigやSecurity Hubによる準拠性監視
- プログラムによる標準的な修復手順の定義
- 包括的なログ記録と監査の実施
- 自動化プロセスの有効性評価
実装手順
- アラートの分析と優先順位付け
- 修復手順の考案とプログラム化
- 修復開始方法の設定
- 修復ログの確認と分析
実装ツール
- AWS Security Hub
- AWS Config
- AWS Lambda
- AWS Systems Manager
- Amazon EventBridge
- Amazon CloudWatch Logs
- Amazon SNS
- AWS IAM
参考