Zenn
Open29

AWS W-A「セキュリティの柱」

AWS
connpass
secjaws
minisecjaws
ピン留めされたアイテム
issyissy

セキュリティの柱

Contents

issyissy

作成中！

issyissy

設計原則

  1. 強力なアイデンティティ基盤を実装する

    • 最小権限の原則を実装
    • 適切な認可による役割分担
    • ID管理の一元化
    • 長期的な認証情報の使用回避

  2. トレーサビリティの維持

    • リアルタイムのモニタリング、アラート、監査
    • ログとメトリクスの自動収集と分析

  3. すべてのレイヤーでセキュリティを適用する

    • 深層防御アプローチの適用
    • すべてのレイヤー（ネットワーク、VPC、インスタンス、OS、アプリケーション等）でのセキュリティ実装

  4. セキュリティのベストプラクティスを自動化する

    • 自動化されたセキュリティメカニズムの導入
    • コードとしてのセキュリティ管理（Infrastructure as Code）

  5. 伝送中および保管中のデータを保護する

    • 伝送中および保管中のデータの暗号化
    • データの分類と適切な保護メカニズムの使用

  6. データに人の手を入れない

    • 自動化ツールの活用によるヒューマンエラーリスクの軽減
    • 機密データへの直接アクセス削減

  7. セキュリティイベントに備える

    • インシデント管理・調査ポリシーの確立
    • インシデント対応シミュレーションの実施
    • 自動化ツールによる迅速な検出、調査、復旧
issyissy

▼セキュリティの基礎

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 との統合
issyissy

SEC01-BP01 アカウントを使用してワークロードを分ける

ベストプラクティスが確立されていない場合のリスクレベル

高

概要

マルチアカウント戦略を採用し、環境とワークロード間に共通ガードレールを設定して分離を確立する。

期待される成果

クラウドオペレーション、無関係のワークロード、環境を別々のアカウントに分類し、セキュリティを向上させるアカウント構造。

一般的なアンチパターン

  • データ重要度の異なるワークロードを同一アカウントに配置
  • 不明確な組織単位（OU）構造

メリット

  • 誤アクセスの影響範囲限定
  • アクセスの一元的ガバナンス
  • セキュリティの一元管理
  • アカウント管理の自動化
  • コンプライアンス対応の集中監査

実装ガイダンス

  1. マルチアカウント戦略

実装手順

  1. 組織単位構造の設計

    • ビジネスニーズ、データ重要度、ワークロード構造に合わせる

  2. ランディングゾーンの作成

    • AWS Control Tower または カスタムビルドを使用

  3. ガードレールの確立

    • AWS Control Tower の必須・オプションコントロールを活用

  4. 新リージョンアクセスの制限

    • IAMリソースの伝播を制御

  5. AWS CloudFormation StackSets の検討

    • 複数アカウント・リージョンへのリソースデプロイを簡素化

実装ツール

  • AWS Organizations: アカウントの階層化管理
  • AWS Control Tower: ランディングゾーン自動設定
  • サービスコントロールポリシー（SCP）: きめ細やかな予防的コントロール
  • AWS Config: 積極的・検出的コントロール
issyissy

SEC01-BP02 セキュアアカウントのルートユーザーおよびプロパティ

ベストプラクティスが確立されていない場合のリスクレベル

高

概要

ルートユーザーは最高権限を持つため、適切な管理と制限が不可欠。ルートユーザーの使用を最小限に抑え、強力な認証と監視を実施する。

期待される成果

ルートユーザー認証情報の不正使用による偶発的または意図的な損害のリスク低減。

一般的なアンチパターン

  • 日常的なタスクでのルートユーザーの使用
  • 緊急時対応計画の定期的なテスト不足
  • 代替アカウント回復方法の考慮・テスト不足
  • DNS、Eメール、携帯電話会社のセキュリティ境界としての扱い不足

メリット

アカウントでのアクションのコントロールと監査の向上

実装ガイダンス

推奨事項は CIS AWS Foundations ベンチマークバージョン 1.4.0
AWS ベストプラクティスガイドラインも参照

  1. 予防的コントロール

    • 正確な連絡先情報の設定
    • ルートユーザーのアクセスキー作成禁止
    • 多要素認証(MFA)の有効化
    • 複雑なパスワードの使用

  2. 検出コントロール

    • ルート認証情報使用の検出アラーム作成
    • Amazon GuardDutyの有効化

  3. 運用ガイダンス

    • ルートユーザー認証情報へのアクセス担当者の決定
    • ルートユーザーの例外的使用
    • 定期的なアクセスチェックと手順テスト
    • インシデント対応手順の準備

実装ツール

  • AWS Organizations
  • AWS Identity and Access Management (IAM)
  • Amazon GuardDuty
  • AWS Config
  • AWS Control Tower
issyissy

セキュリティの基礎: ワークロードを安全に運用する

概要

ワークロードのライフサイクル全体を通じて安全な運用を確保し、組織的なガバナンスアプローチを採用する。

ポイント

  1. ガバナンスの重要性

    • 一貫した意思決定を導くプロセス
    • ワークロードの管理目標達成を確認する方法

  2. 包括的なセキュリティ実践

    • 組織レベルとワークロードレベルでのベストプラクティス適用
    • 脅威モデルと管理目標の継続的な更新

  3. オートメーションの活用

    • プロセスの一貫性と再現性の確保
    • デプロイの信頼性向上とリスク軽減

  4. テストと検証

    • 非運用環境での事前テスト
    • 早期フィードバックによる再作業の削減

  5. 共通機能と共有コンポーネントの利用

    • 複数チームで利用可能なサービスの提供
    • ビルダーのワークロードサイクル時間改善

メリット

  • デプロイの加速
  • 組織全体のセキュリティ機能の向上
  • 一貫したセキュリティ管理目標の達成
  • 管理態勢とリスクポジションの適切な報告

実装のポイント

  • セキュリティプロセスの自動化
  • コードによる設定変更
  • 共通サービス（アカウント作成、ID管理、ログ設定等）の確立
issyissy

▼ID およびアクセス管理

issyissy

ID およびアクセス管理: 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プロバイダーで管理を行っていない
issyissy

ID およびアクセス管理: アクセス許可の管理

管理方法

権限は使用する用途で明確に管理する。そうすることで「誰がどのような条件で何にアクセスできるか」を明確にすることができる。

最小特権の原則を意識するようにします。

ポリシーの定義方法はマネージドポリシーと、インラインポリシーの２つがあります。マネージドポリシーを使用することを推奨します。

  • マネージドポリシー
    • 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

検出

issyissy

概要

主要な２つの検出領域について

  1. 予期しない・望ましくない設定変更の検知
    • Infrastructure as Code(IaC)とCI/CDパイプラインを活用した事前チェック
    • 本番/非本番環境へのデプロイ時のチェック（AWS標準ツール、オープンソース、パートナーツール）
    • 運用中のアプリケーションにおける予期しない設定変更の監視
  2. 想定外動作の検知
    • Amazon GuardDutyによる不正/悪意のある活動の検知
    • 異常なAPIコールの監視
    • セキュリティ設定を変更するAPIコールの明示的なモニタリング

検出の重要性と実装について

  • セキュリティライフサイクルの重要な構成要素として機能
  • 品質管理、法的義務、コンプライアンス要件への対応をサポート
  • ワークロードログの分析による脆弱性の特定
  • 定期的な検出メカニズムの見直しによる要件充足の確認
  • 自動化されたアラートと通知の設定による迅速な対応体制の確立

この検出の枠組みにより、組織は潜在的なセキュリティリスクを早期に特定し、適切な対応を取ることが可能になります。

issyissy

SEC04-BP01 サービスとアプリケーションのログ記録を設定する

https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/sec_detect_investigate_events_app_service_logging.html

ベストプラクティスを活用しない場合のリスクレベル

高

概要

セキュリティイベントログの保持は、監査、調査、運用における基本原則であり、GRC（ガバナンス、リスク、コンプライアンス）の要件を満たすために必要不可欠

期待される効果

  • セキュリティイベントログの確実かつ一貫性のある取得
  • タイムリーな情報アクセス
  • ログの一元化による運用効率の向上

一般的なアンチパターン

  • ログの不適切な保持期間設定（永久保存または即時削除）
  • 無制限のログアクセス許可
  • 手動プロセスへの過度な依存
  • 無差別なログ収集
    • ※ 基本はすべてのログを保存する。そのうえで、必要ないものを判断
  • 必要時のみのログ整合性チェック

メリット

  • セキュリティインシデントの根本原因分析（RCA）の実施が可能
  • GRCの義務における証拠としての活用

実装ガイダンス

  • インシデント調査に必要な関連ログの確実な保存
  • 適切なクエリと取得メカニズムの実装
  • アラート生成メカニズムの確立

実装手順

  1. ログソースの選択（CloudTrail、VPC フローログ、Route 53 Resolver等）
    • ビジネスで必要なユースケースに基づいたものを選択する
  2. 適切なログストレージの選択（S3バケットまたはCloudWatch Logs）
    • S3はライフサイクル
    • CloudWatch Logs はCloudWatch Logs Insightsで効率的に分析できる
  3. 保持期間とライフサイクルポリシーの設定
    • セキュリティ要件と、法令、規制等を考慮する
  4. 各種AWSサービスの個別ログ設定
  5. クエリメカニズムの実装
    • CloudWatch Logs Insights
    • Amazon S3 + Amazon Athena
    • OpenSearch ServiceとSIEM→GitHub参照
  6. アラート機能の設定
    • セキュリティサービスのアラート機能を利用
      • 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

参考

https://blog.engineer.adways.net/entry/2023/10/20/140000

issyissy

SEC04-BP02 標準化した場所にログ、検出結果、メトリクスを取り込む

https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/sec_detect_investigate_events_logs.html

ベストプラクティスを活用しない場合のリスクレベル

中

概要

セキュリティログ、検出結果、メトリクスを標準化された場所に集約し、効率的な分析と異常検知を可能にする取り組み

期待される効果

  • セキュリティデータの標準化された収集・分析・可視化
  • 複数システムからのデータの効率的な相関分析
  • SIEMなどを活用したタイムリーな対応とエスカレーション

一般的なアンチパターン

  • チーム個別のログ管理による組織戦略との不整合
  • 不十分なアクセス制御
  • データ分類ポリシーの無視
  • データ主権・ローカリゼーション要件の軽視

メリット

  • ログデータからの効果的なインサイト抽出
  • 自動ライフサイクル管理によるコスト削減
  • きめ細かなアクセス制御の実現
  • データの相関分析と可視化の効率化

実装ガイダンス

実装手順

  1. ログアーカイブアカウントとセキュリティツール用アカウントの作成
    • AWS Organizations を使用
    • ログアーカイブ用と、分析などに利用する加工済みを完全に分離した場合など。要件に応じて検討
  2. セキュリティデータの標準化保存場所の設定
    • データレイクアーキテクチャ
  3. データソースの公開設定
    • ETL プロセスが必要な形式ではなく、データソースからエクスポート
  4. アクセスツールの設定と権限管理
    • Amazon Athena、Amazon QuickSight、サードパーティーソリューション

実装ツール

  • AWS Organizations
  • AWS Control Tower
  • Amazon Security Lake
  • AWS Security Hub
  • Amazon Athena
  • Amazon QuickSight
  • Amazon GuardDuty
  • Amazon Inspector
issyissy

SEC04-BP03 セキュリティアラートを相関付けて充実させる

https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/sec_detect_investigate_events_security_alerts.html

ベストプラクティスを活用しない場合のリスクレベル

低

概要

複数のソースから生成されるセキュリティアラートを自動的に相関付け・強化することで、インシデントの正確な特定と対応を実現する取り組み

期待される効果

  • アラートデータの自動的な関連付けと強化
  • イベントの重要度判断の精度向上
  • 監視・調査チームの負担軽減
  • インシデント対応の迅速化

一般的なアンチパターン

  • 複数グループによる重複した調査作業
  • 手動での相関付けとエンリッチメント作業
  • 脅威検出システムの情報のみに依存した重要度判断

メリット

  • 調査担当者の認知負担の軽減
  • データ準備作業の自動化
  • インシデント判断の迅速化
    • 関連付けの手作業を軽減することで判断までの時間短縮
  • イベントの重要度評価の精度向上
    • 単独のイベントだけでなく複数イベントを組み合わせることで実際の重要度が評価できる

実装ガイダンス

  • 複数のAWSセキュリティサービスからのアラート統合
    • イベント管理 (SIEM) ツールと統合
  • アイデンティティ、アクション、リソース間のマッピング作成
  • Amazon Detectiveによるアラートの視覚的グラフ化
  • コンテキストに基づいた重要度の動的調整

実装手順

  1. セキュリティアラート情報ソースの特定と分析
  2. アラート集約メカニズムの確立
  3. 相関付け・エンリッチメントソースの特定
  4. アラートとデータソースの統合による詳細なコンテキスト作成

実装ツール

  • Amazon GuardDuty
  • AWS Security Hub
  • Amazon Detective
  • Amazon EventBridge
  • Amazon CloudWatch
  • AWS Lambda
  • Amazon Athena
  • Amazon Security Lake
  • Amazon OpenSearch Service
  • AWS CloudTrail

参考

https://dev.classmethod.jp/articles/amazon-detective-radial-layout/

issyissy

SEC04-BP04 非準拠リソースの修復を開始する

https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/sec_detect_investigate_events_noncompliant_resources.html

ベストプラクティスを活用しない場合のリスクレベル

低

概要

非準拠リソースを検出した際のプログラムによる修復手順の定義と実行を通じて、迅速かつ一貫した対応を実現する取り組み

期待される効果

  • 標準的な修復手順のプログラム化
  • 手動または自動での修復実行
  • 非準拠リソースの効率的な検知と通知
  • 適切な監視と制御メカニズムの確立

一般的なアンチパターン

  • 不十分なテストによる自動修復の実装
  • 人間の介入メカニズムの欠如
  • インシデント対応・復旧プログラムとの不統合

メリット

  • 構成ミスへの迅速な対応
  • 一貫した修復プロセスの実現
  • 人為的ミスのリスク軽減
  • 大規模環境での効率的な処理

実装ガイダンス

  • AWS ConfigやSecurity Hubによる準拠性監視
  • プログラムによる標準的な修復手順の定義
  • 包括的なログ記録と監査の実施
  • 自動化プロセスの有効性評価

実装手順

  1. アラートの分析と優先順位付け
  2. 修復手順の考案とプログラム化
  3. 修復開始方法の設定
  4. 修復ログの確認と分析

実装ツール

  • AWS Security Hub
  • AWS Config
  • AWS Lambda
  • AWS Systems Manager
  • Amazon EventBridge
  • Amazon CloudWatch Logs
  • Amazon SNS
  • AWS IAM

参考

https://qiita.com/maru3ka9/items/a7044543092770be7057

https://aws.amazon.com/jp/solutions/implementations/automated-security-response-on-aws/

https://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/security-incident-response-guide.html

issyissy

インフラストラクチャ保護

issyissy

概要

「インフラストラクチャの保護」は AWS Well-Architected フレームワークのセキュリティの柱における重要な要素で、以下の主要ポイントが含まれています：

基本概念

  • 多層防御の制御手法を活用し、組織や規制上の義務に準拠するための保護策
  • 情報セキュリティプログラムの不可欠な部分として機能
  • 不正アクセスや脆弱性からワークロードを保護する仕組み

主要な保護要素

  • 信頼境界（ネットワーク境界、アカウント境界）の定義
  • システムセキュリティの適切な設定と維持管理（強化、最小化、パッチ適用）
  • オペレーティングシステムの認証と承認の管理
  • ポリシー適用ポイント（WAF、APIゲートウェイなど）の実装

AWS グローバルインフラストラクチャの構成要素

  1. リージョン

    • 世界中の物理的ロケーションにあるデータセンター集積地
    • データレジデンシー要件への対応とコンプライアンス確保

  2. アベイラビリティーゾーン (AZ)

    • 各リージョン内の独立した物理的データセンターグループ
    • 独立した電源、冷却、物理セキュリティを持つ
    • 高帯域幅・低レイテンシーの暗号化ネットワークで相互接続
    • 複数AZ構成によって高可用性と障害耐性を実現

  3. AWS Local Zones

    • エンドユーザーに近い場所に特定のAWSサービスを配置
    • 低レイテンシー（10ミリ秒未満）を要求するアプリケーション向け
    • AWSリージョンの拡張として機能し、主要サービスをローカルで提供

  4. AWS Outposts

    • オンプレミス環境でAWSサービスとインフラを提供
    • 一貫したハイブリッドエクスペリエンスの実現
    • 低レイテンシーやローカルデータ処理が必要なワークロードに対応

AWS Well-Architected フレームワークでは、これらの要素を適切に組み合わせ、多層的な防御アプローチでインフラストラクチャを保護することを推奨しています。

ネットワークの保護

  • SEC05-BP01 ネットワークレイヤーを作成する
  • SEC05-BP02 ネットワークレイヤー内のトラフィックフローを制御する
  • SEC05-BP03 検査に基づく保護を実装する
  • SEC05-BP04 ネットワーク保護を自動化する

コンピューティングの保護

  • SEC06-BP01 脆弱性管理を実行する
  • SEC06-BP02 強化されたイメージからコンピューティングをプロビジョニングする
  • SEC06-BP03 手動管理とインタラクティブアクセスを削減する
  • SEC06-BP04 ソフトウェアの整合性を検証する
  • SEC06-BP05 コンピューティング保護を自動化する
issyissy

SEC05-BP01 ネットワークレイヤーを作成する

ベストプラクティスが確立されていない場合のリスクレベル

高

概要

ネットワークレイヤー作成のベストプラクティスは以下

  • ワークロードコンポーネントをデータの機密度とアクセス要件に基づいて論理的に分離
  • 適切なネットワークトポロジを構築

期待される効果

  • データの機密度とアクセス要件に応じて適切に配置されたネットワークレイヤー
  • ID認証・認可戦略と連携した多層防御セキュリティ
  • 適切に機能するトラフィックフローと統制メカニズム

一般的なアンチパターン

  • すべてのリソースを単一のVPCやサブネットに配置する
  • データの機密度要件やコンポーネントの特性を考慮せずにネットワーク設計を行う
  • AWSマネージドサービスがネットワークトポロジに与える影響を無視する

メリット

  • 不要なネットワーク経路を制限し、重要システム・データへのアクセスを保護
  • 攻撃者によるネットワークアクセスやリソース操作を困難にする
  • 侵入検知やマルウェア防止システムの分析範囲を狭め、誤検出や処理オーバーヘッドを軽減

実装ガイダンス

1. 機能に基づくレイヤー分け

典型的な3層ウェブアプリケーションの例：

  • プレゼンテーションレイヤー: Amazon S3に静的ファイルを保存し、CloudFrontから配信
  • アプリケーションレイヤー: パブリックサブネット(DMZ)にALBを配置し、プライベートサブネットにバックエンドサービスをデプロイ
  • データレイヤー: 別のプライベートサブネットにデータベースや共有ファイルシステムを配置

2. データの機密度に基づく分割

同じアプリケーションレイヤー内でも、データの機密度が異なるサービスには：

  • 複数のプライベートサブネット
  • 同一AWSアカウント内の異なるVPC
  • 異なるAWSアカウントの異なるVPC

3. コンポーネントの動作に基づく分離

高リスクの入力を受け付けるサービス（ファイルアップロード、コードスクリプト実行、メールスキャンなど）は独自のネットワークレイヤーに配置し、強固な分離境界を確立。

4. AWSマネージドサービスの活用

  • VPC Latticeによるネットワークレイヤー間の相互運用性の向上
  • Lambda関数はVPCサブネットにデプロイ
  • VPCエンドポイントやAWS PrivateLinkによるセキュリティポリシー遵守の簡素化

実装手順

  1. ワークロードのアーキテクチャを見直し、機能・データ機密度・動作に基づいてコンポーネントをグループ化
  2. インターネット向けコンポーネントには、マネージドサービス（CloudFront、API Gateway、ELB、Amplify）を活用してパブリックエンドポイントを設置
  3. コンピューティング環境（EC2、Fargate、Lambda）のコンポーネントは、グループに基づいてプライベートサブネットにデプロイ
  4. フルマネージド型AWSサービス（DynamoDB、Kinesis、SQS）へのアクセスにはVPCエンドポイントを使用

このアプローチにより、セキュアで堅牢なネットワークアーキテクチャが実現します。

実装ツール

  • Amazon VPC Lattice
  • AWS PrivateLink
issyissy

SEC05-BP02 ネットワークレイヤー内のトラフィックフローを制御する

ベストプラクティスが確立されていない場合のリスクレベル

高

概要

ネットワークレイヤー内でさらにセグメンテーションを行い、各ワークロードに必要なフローのみにトラフィックを制限します。まず外部からの「North-South」トラフィックの制御に着目し、次にコンポーネント間の「East-West」トラフィックを確認します。

  • North-South・・・データセンターを出入りするトラフィック。ここでは、インターネットからのトラフィックや、VPC間のトラフィック。
  • East-West・・・データセンター内のデバイス間のトラフィック。ここでは、VPC内でのトラフィック。

期待される効果

ワークロードのコンポーネントが必要とする通信フローのみを許可します。パブリック/プライベートの送受信、データ分類、地域の規制、プロトコル要件などを考慮した設計とし、最小特権の原則に基づき、ネットワークピアリングよりもポイントツーポイントのフローを優先します。

一般的なアンチパターン

  • ネットワークレイヤーの境界でのみトラフィックフローを制御する境界ベースのアプローチ
  • ネットワークレイヤー内のすべてのトラフィックが認証済み・承認済みと仮定すること
  • 受信または送信のいずれか一方のトラフィックにのみ制御を適用すること
  • トラフィックの認証と認可をワークロードコンポーネントとネットワーク制御のみに依存すること

メリット

  • ネットワーク内の不正な移動リスクを軽減
  • ワークロードに承認のレイヤーを追加
  • セキュリティインシデントによる影響範囲を制限
  • インシデント検出と対応を迅速化

実装ガイダンス

  1. ネットワークセグメンテーション:

    • Amazon VPC内のサブネットを使用してIP範囲ベースの区分
    • ビジネスドメインごとに異なるVPCを使用したセグメンテーション
    • 複数VPC環境ではAWS Transit Gatewayでルーティング

  2. トラフィック制御:

    • セキュリティグループとルートテーブルによるレイヤー4レベル(IPアドレス/ポート)の制御
    • AWS PrivateLink、Route 53 Resolver DNS Firewall、AWS Network Firewall、AWS WAFでの強化

  3. 通信フローの体系的な調査と文書化:

    • 通信元と通信先の特定: どのサービス/コンポーネントが通信を開始し、どのサービス/コンポーネントがその通信を受信するか
    • 通信プロトコルの特定: 各接続で使用されるプロトコル(HTTP/S、TCP、UDP、ICMP等)
    • ポート番号の特定: 通信に使用される特定のポート番号(例：80/443/3306等)
    • ネットワーク層の特定: 通信が発生するネットワーク層(パブリックサブネット、プライベートサブネット等)
    • 通信の頻度と重要度: 定期的な通信か、緊急時のみか、ビジネスクリティカルかどうか
    • データの分類: やり取りされるデータの機密レベル(機密情報、個人情報、一般情報等)

  4. セキュリティグループの活用:

    • ENI(Elastic Network Interface)を使用するリソースに適用
    • セキュリティグループIDを参照したルールによる柔軟な設定
    • インバウンド・アウトバウンド両方のルールでの制御

  5. VPC間通信の制御:

    • シンプルなルーティングにはVPCピアリング
    • 複雑なルーティングにはAWS Transit Gateway
    • 特定コンポーネント間のみの通信にはAWS PrivateLinkを検討

  6. DNS制御:

    • Route 53 ResolverでDNSファイアウォールルールを作成
    • より詳細な検査にはAWS Network Firewallを検討

実装手順

  1. ワークロードのコンポーネント間で必要なデータフローを特定する
  2. セキュリティグループやルートテーブルを使用し、インバウンドとアウトバウンドの両方に多層防御アプローチを適用する
  3. Route 53 Resolver DNS Firewall、AWS Network Firewall、AWS WAFなどのファイアウォールを使用し、VPCの出入りトラフィックを制御する
    • AWS Firewall Managerを活用して組織全体でのファイアウォールルールを一元管理

実装ツール

  1. セグメンテーションツール

    • Amazon VPC (サブネット、ルートテーブル)
    • AWS Transit Gateway (複雑なVPC間ルーティング)
    • AWS PrivateLink (ポイントツーポイント接続)

  2. トラフィック制御ツール

    • セキュリティグループ (ENIレベルのステートフルファイアウォール)
    • ネットワークACL (サブネットレベルのステートレスファイアウォール)
    • Route 53 Resolver DNS Firewall (DNSレベルの制御)
    • AWS Network Firewall (詳細なパケットインスペクション)
    • AWS WAF (ウェブトラフィックフィルタリング)

  3. 管理ツール

    • AWS Firewall Manager (組織全体のファイアウォールポリシー一元管理)
    • AWS Security Hub (セキュリティコントロールの統合管理)
    • Amazon VPC Flow Logs (トラフィックの可視化と監視)
    • AWS Config (ネットワーク設定の監査と変更追跡)
    • Amazon Detective (セキュリティ調査のためのイベント分析)
issyissy

SEC05-BP03 検査に基づく保護を実装する

ベストプラクティスが確立されていない場合のリスクレベル

中

概要

ネットワークレイヤー間にトラフィックの検査ポイントを設定し、転送中のデータが予想されるカテゴリやパターンと一致しているかを確認します。トラフィックフロー、メタデータ、パターンを分析することで、イベントの識別、検出、対応をより効果的に行います。

期待される効果

ネットワークレイヤー間を通過するトラフィックが検査され、承認されます。許可/拒否の決定は明示的なルール、脅威インテリジェンス、ベースラインからの逸脱に基づいて行われます。機密データに近づくにつれて保護は厳格化されます。

一般的なアンチパターン

  • ポートとプロトコルに基づくファイアウォールルールのみに依存し、インテリジェントシステムを利用していない
  • 特定の最新の脅威パターン（変更される可能性がある）に基づいてファイアウォールルールを作成
  • トラフィックの一部区間（プライベート→パブリック、パブリック→インターネット）のみを検査
  • ネットワークトラフィックのベースライン（動作の異常を比較する基準）がない

メリット

  • インテリジェントなルールによるトラフィックの許可/拒否判断
  • AWSやパートナーが提供する最新の脅威インテリジェンスに基づくマネージドルールセットの活用
  • ルール維持や侵害兆候調査のオーバーヘッド削減
  • 誤検出率の低減

実装ガイダンス

  1. インライン検査の実装:
    • AWS Network Firewall（Suricata互換のIPS仕様対応）の活用
    • Gateway Load Balancer (GWLB)背後のAWS Marketplace製ファイアウォール/IPSの導入
    • 様々なデプロイモデル（VPC単位、検査用VPC集中型、ハイブリッド）の検討
    • TLSラップ解除機能の確認（双方向トラフィックフローのディープパケット検査が可能に）

  1. アウトオブバンド検査の実装:

    • VPCトラフィックミラーリングの設定（プロミスキャスモードのネットワークインターフェイスからのpcap分析など）
    • AWS Marketplaceで提供されるアプライアンスの仮想バージョンの活用

  2. HTTPベースのトラフィック保護:

    • AWS WAFによるウェブアプリケーション保護
    • API Gateway、CloudFront、AWS AppSync、ALBへの送信前にリクエストをフィルタリング
    • AWSマネージドルールと独自ルールの組み合わせ、またはパートナー統合の活用

  3. 一元管理:

    • AWS Firewall Managerによる組織全体でのAWS WAF、Shield Advanced、Network Firewall、VPCセキュリティグループの管理

実装手順

  1. 検査ルールの適用範囲を決定（検査用VPC集中型または各VPC個別など）

  2. インライン検査ソリューションの場合:

    • AWS Network Firewall: ルール、ファイアウォールポリシー、ファイアウォールを作成し、トラフィックをエンドポイントにルーティング
    • GWLB+サードパーティ製アプライアンス: 複数AZにアプライアンスをデプロイし、GWLB、エンドポイントサービス、エンドポイントを作成してルーティングを設定

  3. アウトオブバンド検査ソリューションの場合:

    • 必要なインターフェイスでVPCトラフィックミラーリングを有効化
    • EventBridgeルール+Lambda関数で新リソース作成時に自動的にミラーリングを有効化
    • トラフィックミラーリングセッションをNetwork Load Balancerに送信

  4. インバウンドウェブトラフィック保護の場合:

    • AWS WAFのウェブアクセスコントロールリスト(ウェブACL)を設定
    • デフォルトアクション(ALLOW/DENY)と逐次処理されるルールコレクションを定義
    • ウェブACLをAWSリソース(ALB、API Gateway、CloudFrontなど)に関連付け

実装ツール

  1. インライン検査ツール

    • AWS Network Firewall (Suricata互換のIPS機能搭載)
    • Gateway Load Balancer (GWLB) + AWS Marketplaceの仮想アプライアンス
    • AWS WAF (HTTPベースのトラフィック保護)

  2. アウトオブバンド検査ツール

    • VPC Traffic Mirroring (トラフィックミラーリング)
    • AWS Marketplaceのpcap分析ツール

  3. ルール管理ツール

    • AWS マネージドルール (WAF、Network Firewall用)
    • AWS Firewall Manager (組織全体のポリシー一元管理)
    • AWS Security Hub (セキュリティ状態の可視化)

  4. 自動化ツール

    • Amazon EventBridge + AWS Lambda (検査の自動化)
    • AWS CloudFormation/CDK (検査インフラのコード化)
issyissy

SEC05-BP04 ネットワーク保護を自動化する

ベストプラクティスが確立されていない場合のリスクレベル

中

概要

Infrastructure as Code (IaC) やCI/CDパイプラインなどのDevOpsプラクティスを活用して、ネットワーク保護のデプロイを自動化します。これにより、ネットワーク保護の変更をバージョン管理システムで追跡し、変更のデプロイ時間を短縮でき、設定の逸脱を検知できます。

期待される効果

ネットワーク保護がテンプレートに定義され、バージョン管理システムに保存されます。変更が加えられると、自動パイプラインが起動して、テストとデプロイを調整します。ポリシーチェックや静的テストによりデプロイ前に変更を検証し、ステージング環境で統制の機能を確認します。承認後は本番環境への自動デプロイが実行されます。

一般的なアンチパターン

  • 個々のワークロードチームにネットワークスタック、保護、自動化の完全な定義を任せ、標準的な側面を中央で公開していない
  • ネットワーク、保護、自動化のすべての側面を中央のネットワークチームに一任し、ワークロード固有の側面を各チームに委任していない
  • 一元管理と委任のバランスは取れているが、一貫したテスト・デプロイ標準が全IaCテンプレートとCI/CDパイプラインに適用されておらず、テンプレートの準拠状況確認に必要な設定がツールに組み込まれていない

メリット

  • バージョン管理システムによる変更の追跡と比較
  • 自動化によるプロセスの標準化と予測可能性の向上
  • デプロイ成功率の向上
  • 手動設定の繰り返し作業を削減

実装ガイダンス

  1. マネージドルールシステムの活用

    • AWS WAFマネージドルール
    • AWS Shield AdvancedアプリケーションレイヤーのDDoS自動緩和
    • AWS Network Firewallマネージドルールグループ（レピュテーションの低いドメインリスト、脅威シグネチャを自動更新）

  2. DevOpsプラクティスの適用

    • CloudFormationや他のIaCツールでネットワークリソース、保護、ルールを定義
    • バージョン管理システムへのコミット
    • CI/CDパイプラインによるデプロイ
    • CloudFormation Guardなどのツールによる自動テスト
    • 目的の構成からの逸脱検知

  3. 一元管理アプローチ

    • 専用のネットワークインフラストラクチャアカウントでVPCを定義
    • AWS Security Reference Architecture (AWS SRA)の活用
    • 他アカウントのワークロード、セキュリティグループ、Network Firewall、Route 53構成などを一元定義
    • AWS Resource Access Managerを使用したリソース共有

  4. ハイブリッドモデルの構築

    • 特定の統制を一元的にデプロイして共有
    • 他の統制を個々のワークロードチームとそれぞれのアカウントに委任

実装手順

  1. ネットワークと保護の一元的に定義する側面とワークロードチームで管理できる側面の所有権を明確化
  2. ネットワークとその保護の変更をテスト・デプロイする環境（ネットワークテストアカウント・本番アカウント）の作成
  3. テンプレートのバージョン管理システムへの保存と管理方法の決定（中央テンプレートは別リポジトリ、ワークロードテンプレートはワークロード固有リポジトリに保存）
  4. テンプレートをテスト・デプロイするCI/CDパイプラインの作成と設定ミスチェック、会社標準準拠確認テストの定義

実装ツール

  1. インフラストラクチャ定義ツール

    • AWS CloudFormation
    • AWS CDK (Cloud Development Kit)
    • Terraform
    • AWS Service Catalog

  2. バージョン管理・CI/CDツール

    • AWS CodeCommit / GitHub / GitLab
    • AWS CodePipeline
    • AWS CodeBuild
    • AWS CodeDeploy

  3. テスト・検証ツール

    • CloudFormation Guard
    • cfn-lint
    • cfn-nag
    • AWS Config

  4. モニタリング・コンプライアンスツール

    • AWS Config
    • AWS Security Hub
    • AWS CloudTrail
    • Amazon EventBridge

  5. 共有・一元管理ツール

    • AWS Resource Access Manager (RAM)
    • AWS Organizations
    • AWS Control Tower
issyissy

SEC06-BP01 脆弱性管理を実行する

ベストプラクティスが確立されていない場合のリスクレベル

高

概要

コード、依存関係、インフラストラクチャ内の脆弱性のスキャンとパッチ適用を頻繁に実施し、新しい脅威から保護します。

期待される効果

ワークロードを継続的にスキャンするソリューションが実装され、ソフトウェアの脆弱性、潜在的な欠陥、意図しないネットワーク露出を検出します。リスク評価基準に基づいた脆弱性の特定、優先順位付け、修正のためのプロセスと手順が確立され、コンピューティングインスタンスには自動パッチ管理が実装されます。また、CI/CDパイプライン内でのソースコードスキャンを通じて、脆弱性管理プログラムがソフトウェア開発ライフサイクルに統合されています。

一般的なアンチパターン

  • 脆弱性管理プログラムが存在しない
  • 重大度やリスク回避を考慮せずにシステムパッチ適用を実施
  • ベンダーが提供する耐用年数(EOL)を過ぎたソフトウェアの使用
  • セキュリティの問題分析前に本番環境へコードをデプロイ

メリット

  • 潜在的なセキュリティ脆弱性の早期発見と対応
  • セキュリティインシデントのリスク軽減
  • コンプライアンス要件への適合
  • システムの安定性と信頼性の向上
  • セキュリティ対策のコスト効率化（早期発見による修復コスト削減）

実装ガイダンス

  1. 責任共有モデルの理解：

    • AWS責任共有モデルに基づき、ユーザーはデータ、セキュリティ設定、EC2インスタンスやS3オブジェクトなどのサービス管理に責任を持つ
    • AWSは基盤となるインフラストラクチャ（ハードウェア、ソフトウェア、ネットワーク、施設）の保護を担当

  2. 包括的な脆弱性管理プロセス：

    • セキュリティスキャン、問題の特定・優先順位付け、脆弱性解決のためのパッチ適用を含む
    • 自動化を活用した継続的なモニタリングとスキャンの実施

  3. AWSサービスの活用：

    • Amazon Inspector：ソフトウェア脆弱性や意図しないネットワークアクセスの継続的スキャン
    • AWS Systems Manager Patch Manager：EC2インスタンス間のパッチ適用管理
    • AWS Security Hub：セキュリティチェックの自動化、アラートの一元化、組織全体のセキュリティ体制の可視化
    • Amazon CodeGuru Security：開発フェーズでのJavaおよびPythonアプリケーションの静的コード分析

  4. 開発ライフサイクルへの統合：

    • 脆弱性管理プラクティスをソフトウェア開発ライフサイクルに組み込み
    • 本番環境導入前の予防的な脆弱性解決によるセキュリティリスクの軽減

実装手順

  1. 責任共有モデルを理解する：AWS責任共有モデルを確認し、クラウド内のワークロードとデータ保護の責任を把握

  2. 脆弱性スキャンの実装：Amazon Inspectorなどのサービスを設定し、コンピューティングインスタンス（VM、コンテナ、サーバーレス関数）の自動スキャンを実施

  3. 脆弱性管理プロセスの確立：

    • 脆弱性の特定、優先順位付け、修正のためのプロセスと手順を定義
    • 定期的なスキャンスケジュール、リスク評価基準、重大度に基づく修復スケジュールの設定

  4. パッチ管理の設定：AWS Systems Manager Patch Managerを使用し、OSとアプリケーションのパッチ適用を自動化

  5. マルウェア保護の設定：

    • Amazon GuardDutyによるEC2/EBSボリューム内のマルウェア分析・検出
    • S3に新たにアップロードされるオブジェクトのスキャンと潜在的マルウェア検出

  6. CI/CDパイプラインへの脆弱性スキャン統合：

    • Amazon CodeGuru Securityやオープンソースツールの活用
    • ソースコード、依存関係、アーティファクトのセキュリティ問題検出

  7. セキュリティモニタリングサービスの設定：AWS Security Hubによる複数クラウドサービスのセキュリティ体制の包括的把握

  8. ウェブアプリケーションのペネトレーションテスト実施：必要なスキルや外部支援を活用した脆弱性の特定

  9. Infrastructure as Codeでの自動化：AWS CloudFormationなどのIaCツールによるセキュリティサービスのデプロイと設定の自動化

  10. モニタリングと継続的な改善：脆弱性管理プログラムの有効性の継続的評価と改善

実装ツール

  1. 脆弱性スキャンツール

    • Amazon Inspector（インフラとソフトウェアの脆弱性検出）
    • Amazon ECR画像スキャン（コンテナイメージの脆弱性スキャン）
    • Amazon CodeGuru Security（Javaと Python のコード分析）
    • OWASP ZAP、SonarQube（オープンソース選択肢）

  2. パッチ管理ツール

    • AWS Systems Manager Patch Manager
    • AWS Systems Manager Maintenance Windows
    • AWS Systems Manager State Manager

  3. マルウェア保護ツール

    • Amazon GuardDuty Malware Protection
    • Amazon S3 Malware Protection

  4. モニタリングと管理ツール

    • AWS Security Hub
    • Amazon EventBridge
    • AWS CloudTrail
    • AWS Config

  5. 自動化ツール

    • AWS CloudFormation
    • AWS CDK
    • AWS Lambda（セキュリティ対応の自動化）
    • AWS Step Functions（複雑なセキュリティワークフロー）
issyissy

SEC06-BP02 強化されたイメージからコンピューティングをプロビジョニングする

ベストプラクティスが確立されていない場合のリスクレベル

高

概要

強化されたイメージからランタイム環境をデプロイすることで、ランタイム環境への意図しないアクセスの機会を減らします。コンテナイメージやアプリケーションライブラリなどのランタイム依存関係は、信頼できるレジストリからのみ取得し、その署名を検証します。独自のプライベートレジストリを作成して、ビルドおよびデプロイのプロセスで使用する、信頼できるイメージとライブラリを保存します。

期待される効果

コンピューティングリソースは、強化されたベースラインイメージからプロビジョニングされます。外部依存関係は信頼できるレジストリからのみ取得され、署名が検証されます。これらはプライベートレジストリに保存され、ビルドおよびデプロイプロセスで参照できます。イメージと依存関係は定期的にスキャンされ、新たな脆弱性に対応するために更新されます。

一般的なアンチパターン

  • 信頼できるレジストリからイメージとライブラリを取得しているが、使用前に署名検証や脆弱性スキャンを行っていない
  • イメージを強化しているが、新たな脆弱性がないか定期的にテストしたり、最新バージョンに更新したりしていない
  • イメージの想定ライフサイクル中に不要なソフトウェアパッケージをインストールしている、または削除していない
  • 本番環境のコンピューティングリソースにパッチ適用のみを行い、強化された標準への準拠維持や潜在的マルウェアの削除を怠っている

メリット

  • 権限のないユーザーやサービスへの意図しないアクセスを許可する可能性のあるパスの数を削減
  • 不正アクセスが発生した場合の影響範囲の低減
  • セキュリティインシデントのリスク軽減
  • コンプライアンス要件への適合の容易化
  • 環境全体の一貫性と予測可能性の向上

実装ガイダンス

  1. システム強化の基本アプローチ:

    • OSやコンテナイメージ、アプリケーションライブラリを最新バージョンに更新
    • 既知の問題へのパッチ適用
    • 不要なアプリケーション、サービス、ドライバー、デフォルトユーザー、認証情報の削除
    • ポートの無効化など、必要最小限のリソースと機能のみを備えた環境の作成
    • 監視や脆弱性管理に必要なソフトウェア・エージェントの追加

  2. 信頼できるガイダンスの活用:

    • Center for Internet Security (CIS)のベンチマーク
    • Defense Information Systems Agency (DISA)のSecurity Technical Implementation Guide (STIG)
    • AWS または APN パートナーが公開したAMIの利用
    • AWS EC2 Image Builderによる構成の自動化

  3. 段階的な強化アプローチ:

    • 強化されていないベースイメージにソフトウェアをインストール
    • CIS統制を段階的に適用し影響をテスト
    • 問題がある場合はDISA STIGでより細かな強化を検討
    • 適用可能な構成を記録し、EC2 Image Builderのレシピに定義

  4. コンテナワークロードの強化:

    • Amazon ECRパブリックリポジトリの強化されたDockerイメージの活用
    • EC2 Image Builderを使用したコンテナイメージの強化

  5. コードパッケージ管理:

    • AWS CodeArtifactなどのプライベートリポジトリと信頼できるパブリックリポジトリの統合
    • パッケージの取得、保存、更新の一元管理
    • Software Composition Analysis (SCA)、Static Application Security Testing (SAST)、
      Dynamic Application Security Testing (DAST)の活用

  6. サーバーレスワークロードの管理:

    • Lambda レイヤーを使用した依存関係の管理
    • 共有される標準依存関係のスタンドアロンアーカイブへの構成
    • 独自のビルドプロセスによるレイヤーの作成と管理

実装手順

  1. オペレーティングシステムの強化:

    • 信頼できるソースからベースイメージを取得
    • EC2 Image Builderを使用したAMIのカスタマイズと強化

  2. コンテナ化されたリソースの強化:

    • セキュリティベストプラクティスに基づくコンテナ設定
    • ビルドパイプラインへのECRイメージスキャン実装
    • イメージリポジトリに対する定期的なCVEスキャン

  3. サーバーレス実装の強化:

    • Lambda レイヤーを使用したアプリケーション関数コードと共有依存ライブラリの分離
    • Lambda コード署名の設定による信頼できるコードの実行保証

実装ツール

  1. イメージ強化ツール:

    • AWS EC2 Image Builder (AMIとコンテナイメージの構築・強化)
    • Amazon Inspector (脆弱性スキャン)
    • AWS Systems Manager (パッチ管理)

  2. コンテナセキュリティツール:

    • Amazon ECR (コンテナレジストリ)
    • Amazon ECR イメージスキャン (脆弱性検出)
    • AWS Container Security (包括的なコンテナ保護)

  3. コードパッケージ管理ツール:

    • AWS CodeArtifact (プライベートリポジトリ)
    • Amazon CodeGuru (コード分析)
    • OWASP Dependency-Check (SCA)

  4. サーバーレスセキュリティツール:

    • AWS Lambda Layers (依存関係管理)
    • AWS Lambda コード署名 (コード完全性検証)
    • AWS Lambda 権限管理
issyissy

SEC06-BP03 手動管理とインタラクティブアクセスを削減する

ベストプラクティスが確立されていない場合のリスクレベル

中

概要

デプロイ、構成、保守、調査のタスクは、可能な限り自動化します。自動化を利用できない場合は、緊急対応が必要な事態や安全なサンドボックス環境でのコンピューティングリソースへの手動アクセスを検討してください。

期待される効果

プログラムスクリプトと自動化ドキュメント（ランブック）が、コンピューティングリソースに対する承認されたアクションをキャプチャします。これらのランブックは変更検出システムによって自動的に開始されるか、人間による判断が必要な場合は手動で開始されます。コンピューティングリソースへの直接アクセスは、自動化を利用できない緊急時にのみ可能です。手動のアクティビティはすべてログに記録され、自動化機能を継続的に改善していくためのレビュープロセスに組み込まれます。

一般的なアンチパターン

  • SSHやRDPなどのプロトコルを使用してEC2インスタンスにインタラクティブにアクセスする
  • /etc/passwdやWindowsローカルユーザーなどの個々のユーザーログインを維持する
  • インスタンスアクセス用のパスワードまたはプライベートキーを複数のユーザー間で共有する
  • 手動でソフトウェアをインストールし、構成ファイルを作成または更新する
  • 手動でソフトウェアを更新するかパッチを適用する
  • インスタンスにログインして問題をトラブルシューティングする

メリット

  • 意図しない変更や設定ミスの運用リスクの軽減
  • SSH/RDPを使用しないことによるコンピューティングリソースアクセス範囲の限定
  • 不正行為に対する一般的な経路の遮断
  • 承認されるアクティビティの全範囲をきめ細かく定義および監査するメカニズムの確立
  • 一貫した再現可能な環境の維持
  • 変更履歴の透明性の向上
  • インシデント対応時間の短縮

実装ガイダンス

  1. 手動アクセスのリスク認識:

    • サーバーがSSHやRDPサービスをリスニングすることで不正アクセス経路が開かれる可能性
    • 手作業による人為的ミスのリスク増加
    • ワークロードインシデント、データ破損、セキュリティ問題の発生リスク
    • 認証情報共有に対する保護の必要性と管理オーバーヘッドの増加

  2. エージェントベースのリモートアクセスソリューションの実装:

    • AWS Systems Managerなどのツールの活用
    • SSMエージェントによる暗号化されたチャネルの自己確立（外部発信リクエストのリスニング不要）
    • VPCエンドポイントを介したチャネル確立の設定

  3. Systems Managerによる細かい制御:

    • 実行可能な自動化、ユーザー、タイミングの厳密な定義
    • インタラクティブアクセスなしでのパッチ適用、ソフトウェアインストール、設定変更の実行
    • リモートシェルアクセスとセッションログの記録
    • AWS CloudTrailによるAPI呼び出しの記録

実装手順

  1. EC2インスタンスにAWS Systems Manager Agent (SSMエージェント)をインストールし、基本AMI構成に組み込まれ自動起動されることを確認

  2. EC2インスタンスプロファイルのIAMロールにAmazonSSMManagedInstanceCoreマネージドIAMポリシーが含まれていることを確認

  3. インスタンス上のSSH、RDP、その他のリモートアクセスサービスを無効化:

    • 起動テンプレートのユーザーデータセクションでのスクリプト実行
    • EC2 Image Builderなどを使用したカスタムAMI構築

  4. EC2インスタンスのセキュリティグループ受信ルールで、ポート22/tcp (SSH)またはポート3389/tcp (RDP)へのアクセスが許可されていないことを確認:

    • AWS Configなどを使用したセキュリティグループ構成ミス検出とアラート実装

  5. Systems Managerでの適切な自動化、ランブック定義、コマンド実行:

    • IAMポリシーによるアクションの実行者と条件の定義
    • 本番環境外での徹底的なテスト
    • インタラクティブアクセスの代替として必要に応じた自動化の呼び出し

  6. AWS Systems Manager Session Managerの使用:

    • 必要に応じたインスタンスへのインタラクティブアクセス提供
    • セッションアクティビティのログ記録有効化
    • Amazon CloudWatch LogsまたはAmazon S3での監査証跡の維持

実装ツール

  1. リモート管理・自動化ツール:

    • AWS Systems Manager (SSM)
    • AWS Systems Manager Session Manager
    • AWS Systems Manager Automation
    • AWS Lambda (自動化プロセスの一部として)

  2. セキュリティ監視・管理ツール:

    • AWS Config (セキュリティグループ構成のモニタリング)
    • AWS CloudTrail (API呼び出しの記録)
    • Amazon CloudWatch Logs (セッションログの保存)
    • Amazon S3 (セッションログの長期保存)

  3. イメージ管理ツール:

    • EC2 Image Builder (カスタムAMIの作成)
    • Amazon Machine Images (AMI)

  4. 権限管理ツール:

    • AWS Identity and Access Management (IAM)
    • AWS Security Token Service (STS)
    • AWS Organizations (クロスアカウント権限の管理)
issyissy

SEC06-BP04 ソフトウェアの整合性を検証する

ベストプラクティスが確立されていない場合のリスクレベル

中

概要

暗号化技術による検証を使用して、ワークロードが使用するソフトウェアアーティファクト（イメージを含む）の整合性を検証します。コンピューティング環境内で行われる不正変更への対策として、暗号化技術によりソフトウェアに署名します。

期待される効果

すべてのアーティファクトが信頼できるソースから取得され、ベンダーのウェブサイトの証明書が検証されます。ダウンロードしたアーティファクトは、署名により暗号化技術を使用して検証されます。独自のソフトウェアは暗号化技術を使用して署名され、コンピューティング環境によって検証されます。

一般的なアンチパターン

  • 定評あるベンダーのウェブサイトを信頼してソフトウェアアーティファクトを入手しているが、証明書の有効期限の通知を無視している。証明書が有効であることを確認せずにダウンロードを続行する
  • ベンダーウェブサイトの証明書を検証するが、ダウンロードしたアーティファクトの暗号化技術による検証を行わない
  • ソフトウェアの整合性の検証をダイジェストまたはハッシュのみに頼っている（ハッシュではアーティファクトが変更されていないことは確認できるが、ソースは検証されない）
  • 独自のソフトウェア、コード、またはライブラリに署名しない（内部デプロイでも署名は必要）

メリット

  • マルウェアがコンピューティング環境に侵入するのを防止
  • コンピューティング環境での不正実行の防止
  • ソフトウェアサプライチェーンの保護
  • 改ざんされたソフトウェアの実行リスクの低減
  • 信頼できないソースからのコードの誤使用防止

実装ガイダンス

  1. 整合性検証の基本理解:

    • ダイジェストやハッシュによる整合性チェックの限界理解（改ざん検出は可能だが、ソースは検証不可）
    • データの来歴確認には信頼できる機関が発行した証明書によるデジタル署名が必要

  2. サードパーティソフトウェアの検証:

    • プロバイダーがデジタル署名検証用のパブリックキーを提供しているか確認
    • AWSが提供するソフトウェアのパブリックキーと検証手順の活用例:
      • EC2 Image Builder: AWS TOEインストールダウンロードの署名検証
      • AWS Systems Manager: SSMエージェントの署名検証
      • Amazon CloudWatch: CloudWatchエージェントパッケージの署名検証

  3. イメージプロセスへの署名検証の組み込み:

    • SEC06-BP02で説明されているイメージの取得と強化プロセスへのデジタル署名検証の統合

  4. AWS Signerの活用:

    • 署名の検証と独自のコード署名ライフサイクル管理
    • AWS LambdaとAmazon Elastic Container Registryとの統合によるコードとイメージの署名検証
    • CI/CDパイプラインへのSignerの組み込みによる署名検証と独自コード・イメージへの署名の自動化

実装手順

  1. サードパーティソフトウェアの署名検証プロセス確立:

    • ベンダーの提供する検証手順の確認と実装
    • 署名検証プロセスの自動化

  2. AWS Signerの設定:

    • コード署名の設定と署名プロファイルの作成
    • 署名ポリシーの定義

  3. AWS LambdaのコードへのSignerの適用:

    • Lambdaコード署名の有効化
    • 署名設定の定義
    • コード署名の検証機能の有効化

  4. ECRコンテナイメージへのSignerの適用:

    • コンテナイメージ署名の設定
    • 署名ポリシーの適用
    • 署名検証の自動化

  5. CI/CDパイプラインへの署名プロセスの統合:

    • ビルドプロセスでの自動署名の実装
    • デプロイ前の署名検証チェックの追加
    • 検証失敗時のデプロイブロック機能の実装

実装ツール

  1. 署名と検証ツール:

    • AWS Signer（コード署名とライフサイクル管理）
    • GnuPG (GPG)（オープンソースの暗号化および署名ツール）
    • AWS Certificate Manager（証明書の管理）

  2. ランタイム検証ツール:

    • AWS Lambda Code Signing
    • Amazon ECR Image Signing
    • AWS Systems Manager State Manager（署名検証の自動化）

  3. CI/CD統合ツール:

    • AWS CodePipeline（署名プロセスのパイプライン統合）
    • AWS CodeBuild（ビルドプロセスでの署名ステップの追加）
    • GitHub Actions or GitLab CI（署名と検証の自動化）

  4. モニタリングと監査ツール:

    • AWS CloudTrail（署名および検証活動の監査）
    • Amazon CloudWatch（署名検証の成功/失敗のモニタリング）
    • AWS Security Hub（整合性検証に関するコンプライアンス状況の確認）
issyissy

SEC06-BP05 コンピューティング保護を自動化する

ベストプラクティスが確立されていない場合のリスクレベル

中

概要

コンピューティング保護操作を自動化して、人的介入の必要性を減らします。自動スキャンを使用してコンピューティングリソース内の潜在的な問題を検知し、プログラムによる自動応答またはフリート管理操作で修正します。CI/CDプロセスに自動化を組み込むことで、最新の依存関係を反映した信頼できるワークロードをデプロイできます。

期待される効果

自動化システムがコンピューティングリソースのすべてのスキャンとパッチ適用を実行します。自動検証によりソフトウェアイメージと依存関係が信頼できるソースから取得され改ざんされていないことを確認します。ワークロードは自動的に最新の依存関係をチェックし、AWS環境での信頼度確立のために署名されます。非準拠リソースが検出されると、自動修復が開始します。

一般的なアンチパターン

  • イミュータブルインフラストラクチャを採用しているが、本番システムの緊急パッチ適用や交換のためのソリューションがない
  • 誤構成リソースを自動修正しているが、手動オーバーライドメカニズムが導入されていない（要件調整が必要な場合、自動化を一時中断する必要がある）

メリット

  • コンピューティングリソースへの不正アクセスと不正使用のリスク軽減
  • 本番環境への構成ミスの波及防止
  • 発生した構成ミスの検知と修正
  • 不正アクセスや不正使用の検知と対応時間の短縮
  • 問題による全体的な影響範囲の縮小
  • 運用効率の向上と人的ミスの削減

実装ガイダンス

  1. 脆弱性管理の自動化:

    • CI/CDパイプラインとランタイム環境でのAmazon Inspectorによる継続的スキャン
    • AWS Systems Managerを使用したパッチ適用
    • 自動ランブックを通じた新イメージからの再デプロイ
    • 手作業プロセスとインタラクティブアクセスの必要性低減

  2. 信頼できるワークロードデプロイの自動化:

    • EC2 Image Builder、AWS Signer、AWS CodeArtifact、Amazon ECRの活用
    • 強化・承認されたイメージとコード依存関係のダウンロード、検証、構築、保存
    • CI/CDプロセスによる依存関係の最新性・信頼性確認
    • ワークロード署名によるAWS環境での実行前検証

  3. 発見的統制の自動化:

    • AWS Security Hubによる各種セキュリティチェック（NIST 800-53 Rev.5標準など）
    • IMDSv2使用確認などのセキュリティ検証
    • 非準拠インスタンスの検出と自動修復

実装手順

  1. 安全なAMI作成の自動化:

    • EC2 Image Builderを使用した安全で規制準拠の強化AMI作成
    • 基本AWS/APNパートナーイメージからCISベンチマークまたはSTIG標準統制の組み込み

  2. 構成管理の自動化:

    • AWS Configによる自動構成管理
    • AWS Security Hubによるセキュリティ・コンプライアンス体制の自動管理

  3. パッチ適用・インスタンス置換の自動化:

    • AWS Systems Manager Patch Managerによるパッチプロセスの自動化
    • オペレーティングシステムとアプリケーション両方へのパッチ適用

  4. セキュリティスキャンの自動化:

    • Amazon Inspectorによる共通脆弱性識別子(CVE)検知
    • ECRイメージスキャンのビルドパイプラインへの組み込み

  5. 脅威検出の自動化:

    • Amazon GuardDutyによるマルウェアと脅威の自動検出
    • Lambda関数呼び出し時の問題特定

  6. AWSパートナーソリューションの活用:

    • 業界をリードする製品による既存統制の補完
    • AWS既存サービスとの統合による包括的セキュリティアーキテクチャの構築
    • ハイブリッド環境全体でのシームレスなセキュリティエクスペリエンスの実現

実装ツール

  1. イメージ管理・強化ツール:

    • AWS EC2 Image Builder
    • Amazon Machine Images (AMI)
    • Amazon ECR

  2. スキャンと脆弱性管理ツール:

    • Amazon Inspector
    • ECRイメージスキャン
    • AWS Systems Manager Patch Manager

  3. 設定管理と適用ツール:

    • AWS Config
    • AWS Security Hub
    • AWS Systems Manager State Manager

  4. 自動修復ツール:

    • AWS Systems Manager Automation
    • AWS Config Rules with Remediation
    • AWS Lambda (カスタム修復ロジック用)

  5. 脅威検出ツール:

    • Amazon GuardDuty
    • Amazon Detective

  6. CI/CD統合ツール:

    • AWS CodePipeline
    • AWS CodeBuild
    • AWS CodeDeploy
    • AWS Signer
    • AWS CodeArtifact