はじめに

こんにちは。よっしーです。
AWSよりAzureの勉強する時間のほうが増えてきている今日この頃です。
社内でもAzureのプロジェクトが立ち上がり、毎週、Well-Architectedフレームワークの勉強会が行われています。

2023の5月時点では、AWSでは6本の柱、Azureでは5本の柱があります。柱の名前もほとんど同じなのは大変興味深いです。

AWS

• オペレーショナルエクセレンスの柱
• セキュリティの柱
• 信頼性の柱
• パフォーマンス効率の柱
• コスト最適化の柱
• 持続可能性の柱

Azure

• 信頼性
• コストの最適化
• オペレーショナル エクセレンス
• パフォーマンス効率
• セキュリティ

柱の名前は同じでも、具体的に中身はどうなのか気になったので、AWSとAzureのWell-Architectedフレームワークの「セキュリティの柱」を比較してみたいと思います。設問と選択肢を書き出しただけで相当のボリュームになってしまったので、今回はまずは第一弾としてAWSの「セキュリティの柱」の質問のリスクレベルが「高」のものに絞って見ていきたいと思います。（設計原則は割愛しています）
それぞれのベストプラクティスの中で出てくるキーワードを書き出して、自分なり解釈を付け足しています。（間違っていたらゴメンなさい🙏）

AWSのセキュリティの柱

発行日: 2023 年 4 月 10 日
以下は2023/05/18現在の内容です

定義

「セキュリティの柱」を構成する7つの領域があります。

• セキュリティの基礎
• ID とアクセス管理
• 検知
• インフラストラクチャ保護
• データ保護
• インシデント対応
• アプリケーションのセキュリティ

質問

「セキュリティの柱」の質問は全部で11個あり、それぞれの質問に対してベストプラクティスがあります。質問にはそれぞれ、「高」「中」「低」のリスクレベルが設定されています。

セキュリティの基礎

• SEC 1. ワークロードを安全に運用するには、どうすればよいですか?
  • アカウントを使用してワークロードを分ける（高）
    • マルチアカウント戦略
    • アカウントレベルでの境界の分離ができているか
    • AWS Organizations、AWS Control Tower
    • ランディングゾーン、ガードレール
    • SCPによる予防的コントロール、AWS Configによる検出的コントロール
  • セキュアアカウントのルートユーザーおよびプロパティ（高）
    • ルートユーザーの定期的な使用を避ける
    • ルートユーザーの多要素認証 (MFA)は必ず有効にする
    • ルートユーザーにはアクセスキーを作成しない
    • Organizationsを使用している場合は、管理アカウントのルートユーザーの保護を優先とし、メンバーアカウントのルートユーザーに対しては、予防的コントロール（SCP）の「ルートユーザーとしてのアクションを許可しない」での保護も検討
  • 管理目標を特定および検証する（高）
    • 脅威モデル
    • コンプライアンス要件を特定する
  • セキュリティ脅威に関する最新情報を入手する（高）
    • 脅威インテリジェンス情報を定期的に確認する
    • 共通脆弱性識別子 (CVE) リスト
  • セキュリティのレコメンデーションに関する更新情報を入手する（高）
    • セキュリティのレコメンデーションを常に最新に保つ
    • AWS セキュリティ速報
    • AWS セキュリティブログ
  • 脅威モデルを使用して脅威を特定し、緩和策の優先順位を付ける（高）
    • ワークロードの潜在的脅威のモデル化
    • STRIDE
    • OWASP Top 10
    • HITRUST 脅威カタログ
  • 新しいセキュリティサービスと機能を定期的に評価および実装する（低）
  • パイプラインのセキュリティコントロールのテストと検証を自動化する（中）

自分なりの解釈
ワークロードに応じたアカウントの分離をしていますか。ルートユーザーの管理を適切に行っていますか。コンプライアンスの要件を決めていますか。日頃からセキュリティ脅威に関する情報を収集していますか。

ID とアクセス管理

• SEC 2. ユーザー ID とマシン ID はどのように管理したらよいでしょうか?
  • 強力なサインインメカニズムを使用する（高）
    • 多要素認証 (MFA)の使用
    • IAM、IAM Identity Center
    • 強力なサインインポリシー
    • NIST 800-63
  • 一時的な認証情報を使用する（高）
    • IAM Roles Anywhere
    • 長期的認証情報（アクセスキー）を使う必要がある場合は、定期的に認証情報を監査し、アクセスキーのローテーションを行う
  • シークレットを安全に保存して使用する（高）
    • 存続期間の長いシークレットの保存
    • API アクセスキー、パスワード、OAuth トークンなど
    • AWS Secrets Manager
      • 保存時、転送時の暗号化
      • 総合的な監査
      • きめ細やかなアクセスコントロール
      • 認証情報のローテーション
  • 一元化された ID プロバイダーを利用する（高）
    • IAM Identity Center
  • ユーザーグループと属性を活用する（低）
  • 定期的に認証情報を監査およびローテーションする（中）
• SEC 3. 人とマシンのアクセス許可はどのように管理すればよいでしょうか?
  • アクセス要件を定義する（高）
    • 各コンポーネントにアクセスできるユーザーや内容を明確に定義し、適切な ID タイプと認証および承認の方法を選択する
    • フェデレーションアクセス
    • 一元化されたIDプロバイダー
    • IAM ロール
    • Secrets Manager
    • IAM Roles Anywhere
  • 最小特権のアクセスを付与します（高）
    • 職務に応じたアクセスポリシー
    • 個人ではなく、グループ（IAMグループ）への最小セットのアクセス許可を付与
    • IAM Access Advisor
    • リソースタグを用いた属性ベースのアクセスコントロール(ABAC)
    • サービスコントロールポリシー(SCP)
    • アクセス許可の定期的なレビュー
    • 職種マトリックス
  • ライフサイクルに基づいてアクセスを管理する（低）
  • パブリックおよびクロスアカウントアクセスの分析（低）
  • 緊急アクセスのプロセスを確立する（中）
  • アクセス許可を継続的に削減する（中）
  • 組織のアクセス許可ガードレールを定義する（中）
  • 組織内でリソースを安全に共有する（中）
  • サードパーティーとリソースを安全に共有する（中）

自分なりの解釈
IAM Identity Centerなどを使用し、IDを一元的に管理していますか。永続的な認証情報はできるだけ使わず一時的な認証情報を使用し、永続的な認証情報を使う場合は、監査を行い、アクセスキーのローテーションをしていますか。アクセスポリシーを定め、最小特権を付与していますか。

検知

• SEC 4. セキュリティイベントは、どのように検出して調査するのですか?
  • サービスとアプリケーションのログ記録を設定する（高）
    • セキュリティイベントログを保持
    • ガバナンス、リスク、コンプライアンス（GRC）共通のセキュリティ要件
    • セキュリティインシデントの根本原因分析 (RCA) メカニズム
    • CloudTrail ログ、VPC フローログ、他
    • CloudWatch ロググループからの CloudWatch Logs Insights
    • Amazon S3 バケットからの Amazon Athena
  • ログ、結果、メトリクスを一元的に分析する（高）
    • ログの集計と分析の自動化
    • Amazon GuardDuty
    • AWS Security Hub
    • セキュリティ情報とイベント管理 (SIEM) システム
  • 実用的なセキュリティイベントを実装する（低）
  • イベントへの応答を自動化する（中）

自分なりの解釈
セキュリティイベントに関するログを集約して保存していますか。それらのログの分析の自動化はしていますか。アラートやインシデントの応答の自動化をしていますか。

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

• SEC 5. ネットワークリソースをどのように保護しますか?
  • ネットワークレイヤーを作成する（高）
    • 階層型ネットワーク
    • プライベートサブネット、パブリックサブネット
    • セキュリティグループ、WAF、他
  • すべてのレイヤーでトラフィックをコントロールする（高）
    • インバウンド、アウトバウンドのトラフィックの制御
    • セキュリティグループ、ネットワーク ACL
    • VPC エンドポイント、AWS PrivateLink
  • 検査および保護を実装する（低）
  • ネットワーク保護を自動化する（中）
• SEC 6. どのようにコンピューティングリソースを保護するのですか?
  • 脆弱性管理を実行する（高）
    • 脆弱性スキャンとパッチ適用
    • Amazon EC2、Amazon ECS、Amazon EKS、Amazon RDS
    • アプリケーションのソースコード
    • Amazon Inspector、AWS Systems Manager Patch Manager
    • Amazon CodeGuru（静的コード分析）
    • CI/CDパイプラインの早期に脆弱性評価を組み込む
  • アタックサーフェスを削減する（高）
    • 攻撃対象領域
    • 意図しないアクセスへの露出を減らす
    • 未使用のコンポーネントを減らす
  • ユーザーが遠距離でアクションを実行できるようにする（低）
  • ソフトウェアの整合性を検証する（低）
  • マネージドサービスを活用する（中）
  • コンピューティング保護を自動化する（中）

自分なりの解釈
パブリックサブネットとプライベートサブネットを分離し、インターネットに公開する必要のないものをパブリックサブネットに置いてませんか。セキュリティグループやNetwork ACLを使いインバウンド、アウトバウンドのトラフィックをコントロールしていますか。VPCエンドポイントやPrivate Linkを使用して、AWSサービスに対して、インターネットを経由せずAWSネットワーク内のプライベートアクセスを実現していますか。
継続的な脆弱性のスキャンとパッチ適応をしていますか。未使用なコンポーネントを減らし、意図しないアクセスを減らしていますか。

データ保護

• SEC 7. どのようにデータを分類していますか?
  • ワークロード内のデータを特定する（高）
    • 重要度と機密性に基づいて組織データをカテゴリ別に分類
    • 機密データをどのように管理しているか（どこに保存し、誰がアクセスできるか）
    • 知的財産 (IP)、保護対象医療情報 (PHI)、個人を特定できる情報 (PII)など
    • Amazon Macie
    • Amazon RDS database with Macie、DynamoDB with Macie
    • AWSリソースのタグ付け
  • データ保護コントロールを定義する（高）
    • 適切なサービスだけが機密コンテンツにアクセスできる
    • リソースタグと属性ベースのアクセスコントロール
    • AWS KMS、キーポリシー
  • データのライフサイクル管理を定義する（低）
  • 識別および分類を自動化する（中）
• SEC 8. 保管中のデータをどのように保護していますか?
  • 安全なキー管理を実装する（高）
    • キーの保存、ローテーション、アクセス制御
    • AWS KMS
    • キーのエイリアス、キーレベルのポリシー
    • AWS CloudHSM
    • FIPS 140-2 レベル 3 検証済みのHSMの使用
  • 保管中に暗号化を適用する（高）
    • AWS KMS
    • AWSマネージドキー、カスタマーマネージドキー
    • ローテーション、キーポリシー、アクセス制御、監査が必要かどうか
    • デフォルト暗号化（Amazon EC2、Amazon S3）
    • AWS Config Rules を使用した暗号化使用の検証（Amazon EBS、Amazon S3、Amazon RDS）
    • AWS Encryption SDK（エンベロープ暗号化）
    • Amazon DynamoDB Encryption Client
    • AWS CloudHSM
  • アクセスコントロールを適用する（低）
  • 人をデータから遠ざけるメカニズムを使用する（低）
  • 保管中のデータの保護を自動化する（中）
• SEC 9. 転送中のデータをどのように保護していますか?
  • 安全な鍵および証明書管理を実装する（高）
    • AWS Certificate Manager (ACM)
    • 暗号化キーと証明書を安全に保存
  • 転送中に暗号化を適用する（高）
    • 安全な TLS プロトコルと暗号スイートを使用する
    • 安全なプロトコルのみを許可
    • Amazon S3バケットポリシー（aws:SecureTransport）
    • AWS Certificate Manager (ACM)
  • ネットワーク通信を認証する（低）
  • 意図しないデータアクセスの検出を自動化する（中）

自分なりの解釈
データの重要度と機密性に応じて、データをカテゴリごとに分類し、管理（保存）していますか。データを暗号化するキーを適切に管理し、保管中のデータ、転送中のデータを暗号化を行っていますか。

インシデント対応

• SEC 10. インシデントの予測、対応、復旧はどのように行いますか?
  • 重要な人員と外部リソースを特定する（高）
    • 組織内の主要な人員を特定する
      • インシデントが発生した際に、インシデント対応と復旧に必要な組織内の人員の連絡先リストはあるか
    • 外部パートナーを特定する
      • 潜在的なリスクや脅威を特定するのに役立つ外部の専門知識を備えたパートナーはいるか
  • インシデント管理計画を作成する（高）
    • インシデント対応の教育とトレーニング
      • プレイブック、ランブック
      • ゲームデーを行いインシデント対応をシミュレーション
      • 「セキュリティは全員の任務と見なす必要があります。」
    • インシデント管理計画をドキュメント化する
      • 責任分担 (RACI) マトリックスを作成
    • インシデントを分類する
      • 重大度と影響度のスコアに基づき分類
      • 高 (H)、中 (M)、低 (L)
      • インシデントをトリアージ
    • セキュリティコントロールを標準化する
      • 一貫性、トレーサビリティ、再現性の実現のため
    • オートメーションを使用する
      • プレイブックとランブックでインシデント対応を構築
      • AWS Systems Manager Incident Manager
    • 根本原因分析と、教訓から得られたアクションを実施します
      • 過去のインシデント対応を教訓とし、再発を防止し、未来のインシデントに対応する能力を身につける
  • ツールを事前デプロイする（低）
  • ゲームデーを実施する（中）
  • フォレンジック機能を備える（中）
  • 封じ込め機能を自動化する（中）
  • アクセスを事前プロビジョニングする（中）

自分なりの解釈
インシデント発生時に、そのインシデントへの対応や復旧に関わる担当者（関係者）を決めていますか。管理計画を立てインシデントを分類し、対応の自動化を行っていますか。ゲームデーを行いインシデント対応をシミュレーションしていますか。

アプリケーションのセキュリティ

• SEC 11. 設計、開発、デプロイのライフサイクル全体を通じて、アプリケーションのセキュリティ特性をどのように組み込み、検証すればよいのでしょうか?
  • 定期的にペネトレーションテストを実施する（高）
    • 自動化されたテストや手動のコードレビューでは検知できない、ソフトウェアの潜在的な問題を識別する
    • ソフトウェア開発ライフサイクル (SDLC) の一部として、定期的かつ計画的にペネトレーションテストを実施する
  • ソフトウェアをプログラムでデプロイする（高）
    • 人的エラーにより予期せぬデプロイの失敗を減らす
    • 原則としてデータへの人的関与を排除
    • AWS CodeBuild、AWS Code Pipeline
    • CloudFormation、AWS CDK
  • パイプラインのセキュリティ特性を定期的に評価する（高）
    • 「セキュリティの柱」の原則を CI/CD パイプラインインフラストラクチャに適用する
    • パイプラインへのアクセス許可は、実施するデプロイに必要なものだけに制限する（最小特権）
    • パイプライン自体のセキュリティを管理する
  • ワークロードチームにセキュリティのオーナーシップを埋め込むプログラムを構築する（低）
  • アプリケーションのセキュリティに関するトレーニングを実施する（中）
  • 開発およびリリースライフサイクル全体を通じてテストを自動化する（中）
  • 手動のコードレビュー（中）
  • パッケージと依存関係のサービスを一元化する（中）

自分なりの解釈
ソフトウェア開発ライフサイクル (SDLC) の一部として、定期的にペネトレーションテストを実施していますか。CI/CD パイプラインを構築し、ソフトウェアのデプロイの自動化を行っていますか。CI/CD パイプライン自体にも適切なアクセス許可を与えるなどのセキュリティのベストプラクティスの自動化をしていますか。

まとめ

振り返りますと、

SEC1. アカウントレベルでの分離とルートユーザーの管理、ワークロードの安全な運用
SEC2. IDの管理、認証
SEC3. アクセス許可、認可（承認）
SEC4. ログ収集、監視
SEC5. 多層防御（ネットワーク）
SEC6. 多層防御（ホスト）、脆弱性管理
SEC7. データの分類
SEC8. 保管中のデータの暗号化
SEC9. 転送中のデータの暗号化
SEC10: インシデント対応
SEC11: ペネトレーションテスト、デプロイとセキュリティベストプラクティスの自動化

今回はざっくり、リスクレベル「高」のものだけ扱いましたが、それだけでもかなりのボリュームでした。どこから手をつけたら良いかわからない方は、まずはリスクレベル「高」のものから優先的に着手して、カバーできるようになったら「中」や「低」ものに広げていくのはいかがでしょうか。
「セキュリティの柱」だけ見ても全てを把握するのはかなりハードルが高いと思いますが、まずは一つの柱をじっくり読んで実践してみるのも良いかと思います。
今回はAWSの「セキュリティの柱」を見てきましたが、次回は同じようにAzureの「セキュリティの柱」を取り上げ、AWSとAzureとではどう違うのか見ていきたいと思います。

ちなみにDWSは、2021年9月に AWS Well-Architected パートナープログラム の認定を取得しています。

Well-Architectedフレームワークについての過去の記事もあるので、こちらもご参照ください。

yoshi