Zenn
Open12

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

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

セキュリティの柱

Contents

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の再利用