3日間セキュリティにどっぷり浸れる！AWS認定トレーニング「Security Engineering on AWS」受講レポート

こんにちは！AWS事業本部のおつまみです。

皆さん、AWS認定トレーニング「Security Engineering on AWS」は知っていますか？

先日こちらのトレーニングを受講したので、どんなことが学べるか内容をお伝えしていきたいと思います。

結論、セキュリティに関する知識を網羅的に学ぶことができる素晴らしい内容でした！
これから受講するかどうか検討している方の参考になればと思います。

コース概要

AWS セキュリティサービスを効率的に使用して、AWS クラウドで安全な環境を維持する方法を示していきます。このコースでは、クラウドのデータとシステムのセキュリティを強化するために AWS で推奨されるセキュリティのプラクティスに焦点を当てます。コンピューティング、ストレージ、ネットワーキング、データベースサービスを含め、AWS が提供する主要サービスのセキュリティ機能をハイライトします。また、自動化、継続的なモニタリングとログ記録、セキュリティ障害への対応のために、AWS のサービスとツールを活用する方法についても学びます。

前提知識や対象受講者などの詳細についてはこちらのブログをご参照ください。

当日の雰囲気

• Zoomでのオンライン参加
• 今回の受講者は10名程度
• 公式テキストを元にトレーナーが解説しながら進める
• 適宜クイズやアンケートで理解度をチェックできる
• なんでも聞いてください！という講師のマインドで心理的安全性が高い
• Slackでも音声でも質問しやすい◎
• 参考リンク集のブログでテキスト外の内容を補強できる（こちらのブログ最強でした）

1日目

モジュール01: AWSのセキュリティ

AWSにおけるセキュリティの仕組みの概要を学ぶ

• セキュリティって何を守るもの？（Slackを使ってみんなで投稿）
• 情報セキュリティの観点で大きく3要素ある
  • 機密性（認可されたユーザーのみにアクセスと開示を制限）
  • 完全性（データの整合性）
  • 可用性（必要な時に情報にアクセスできる）
• AWSクラウド内のセキュリティ
  • 可視性（何がどうなっているの？）：AWS Config
  • 監査可能性(いつ誰がどのようなアクションを実行したのか？)：AWS CloudTrail
  • 可制御性(アクションの許可・拒否)：AWS IAM
  • 俊敏性・オートメーション（高可用性・再現可能な方法で自動デプロイ）：AWS CloudFormation
• AWSの責任共有モデル
  • お客様はクラウド内のセキュリティに責任を持つ
  • AWSはクラウドのセキュリティに責任を持つ
  • サービスによって、責任範囲が異なる
    • インフラストラクチャサービス(EC2・ALBなど)
    • コンテナサービス(RDSなど)
    • AWSの抽象化されたサービス(S3・Lambdaなど)
• インシデント対応の概要
  • AWS Cloud Adoption Framework(CAF)セキュリティの側面
    • 司令：セキュリティ要件は何か
    • 予防：悪い事態が起きるのを阻止する
    • 検出：いずれ起きる悪い事態を探す
    • 対応：検出された悪い事態を修正または警告する
• DevOpsとセキュリティエンジニアリング
  • 運用の自動化・IaCの管理(コードベースのアプローチ)を行う
  • 脅威のモデル化で脆弱性を特定する
  • 侵入テスト：不正なアクティビティをシュミレート
    • 一部を除いたAWSサービス以外は事前にAWSの許可が必要

モジュール02: AWSのエントリポイントを確認する

ユーザがAWSにアクセスする方法、ログの管理について学ぶ

• AWSはIAMに始まり、IAMに終わると言われるぐらい重要なサービス
• ポリシーの書き方を抑えることが肝
• AWSの操作はマネコン・CLI・SDK・その他のAWSサービスから実行する
  • AWSサービスのAPIエンドポイントに対して、APIリクエストを送る
  • IAMで認証・認可、CloudTrailで操作を記録
  • AWSサービスのサービスエンドポイント
    • IAMなどのグローバルサービスはどのリージョンでも同じ
  • APIの署名は自動で行われる
• AWSアカウントのルートユーザとユーザの認証情報
  • アクセスキーは定期的に更新するため2つまで保持できる
  • アクセスキー保護のためのベストプラクティス
    • 定期的な更新
    • 使わない場合は無効化、削除
    • 異なるエンティティには異なるキー
    • 直接コードに埋め込まない
• IAMポリシーを分析
  • 基本IAMグループにIAMポリシーを適用
  • IAMロールはIAMユーザーやグループと同じエンティティに属する（※IAMロール自体には認可の機能はない）
  • アクセス管理
    • アイデンティティベースのアクセス許可(IAM)
    • リソースベースのアクセス許可(バケットポリシー・キーポリシー)
    • サービス内の追加のセキュリティ管理（S3のACL）
  • IAMには信頼ポリシーとアクセス権限ポリシーがある
    • 信頼ポリシー：ロールを引き受けることができるユーザー
    • アクセス権限ポリシー：ロールを引き受けたユーザーが実行できるアクションとリソース
  • クロスアカウント認証：一時的なアクセスに対する委任アプローチ
    • STSから一時的な認証情報を付与する（デフォルトでは最大1時間の制限）
    • 信頼関係を確立する必要がある（AssumeRoleコマンド）
    • IAMポリシーの種類
      • AWS管理ポリシー
        • AWSが自動的に更新および管理する
        • IT業界で使用される職務機能と密接に連携している
        • 古いポリシーは廃止(廃止になっても基本通知は来ない)
        • AdminAccess・PowerUserAccessなど
      • カスタマー管理ポリシー
        • ユーザが作成・管理する
      • インラインポリシー
        • 各エンティティ(IAMグループ・IAMユーザー・IAMロール)への埋め込み
        • ポリシーとエンティティとの現密な1対1の関係
        • 基本あまり使用しない
    • IAMポリシーの理解
      • IAMポリシーエレメント（★・・必須）
        • Effect★：ステートメントの効果を許可または明示的な拒否を指定
        • Action★：特定のアクション
        • Resource★：ステートメントで取り扱うオブジェクトを指定
        • Condition：ポリシーを実行するタイミングの条件を指定
        • Principal：リソースへのアクセスを許可または拒否するエンティティ（リクエスト元）を指定
      • ポリシークイズ！
        • AllowとDeny：明示的なDeny＞明示的なAllow＞暗黙のDeny
        • UserとRole：AssumeRoleした際にRoleは上書きされる
        • 条件によるアクセス制御：各条件のANDで評価
        • ResourceとNotResource：DenyのNotResourceはこのバケット以外を拒否するよの意味、NotResourceはかなり強力！
        • リソースベースポリシー：リソースベースのポリシー＞IAMポリシーが優先される、リソースベースポリシーで許可を書く際は注意！
          • 全てはDenyから始まる → 明示的なDeny
          • リソースベースポリシー → 許可があれば許可
          • その他のポリシー（セッションポリシー・アイデンティティベースポリシー）は最後まで許可があるか確認
      • IAMポリシーの概要
        • JSONポリシードキュメントを読むよりも権限を容易に確認できる
        • IAM Access Analyzer：アカウント内のどのリソースを外部プリンシパルと共有しているか知らせることができる、意図したアクセスか意図しないアクセスかを確認できる
        • ポリシーは細かく書いて、最小権限のみ付与する
      • Permissions Boundary（許可の境界）
        • IAMの機能
        • 本来管理者でない開発者が、ロールや他ユーザーを作成したい場合に使用
        • IAMポリシーと分ける理由
          • IAM管理者のみで権限を管理していた場合、開発者がAWSリソースを操作できる範囲が狭まってしまう。
          • ただ何でもかんでもAWSリソースに権限を与えるのは危険。
          • そのため、Permissions Boundaryでそのアクセス許可の上限を設定できる。
        • ワークフロー
          • 管理者：委任された管理者を作成
          • 委任された管理者：「境界」のユーザーとロールを作成
          • 「境界」のIAMユーザーとロール：AWSリソースへPermisions boundaryで制限したアクセスを許可
      • ロールとセッションポリシー
        • 通常はあまり使わない。
        • AWS環境にSSOやSAMLでログインするとき（フェデレーティッドユーザー）に一時的なセッション時、さらにアクセスを制限する時に使用。
    • 多要素認証
      • MFAには多くの種類がある（仮想・さまざまなタイプのハードウェア・U2Fセキュリティキー・AWSGovCloud）
    • CloudTrailでのAPIリクエストのログ記録
      • イベントはコンソールから7日間、検索・ダウンロードできる
      • 誰が？何を？いつどこで？どんな応答があったか？を記録
      • ベストプラクティス
        • ログを専用アカウントのS3に送信
        • 最小権限の原則を適用
        • ログのS3バケットにMFA削除を適用
        • バージョニングを有効
        • ログファイルの整合性を適用
      • API以外のイベントのログ記録
        • ログインの試行（APIではないけど、記録される）
        • AWSアカウントのルートユーザーの正常に認証されたサインイン試行のみ

ラボ01: トランザクション＆リソースベース ポリシーの利用

アイデンティティベースポリシーとリソースベースポリシーの違いを理解する

モジュール03: セキュリティに関する考慮事項: Webアプリケーション環境

3層ウェブアプリケーション環境のセキュリティに関する考慮事項を学ぶ

• リスク評価とは何か
  • 資産(アセット)・脅威・脆弱性が重なるところにリスクがある
  • コントロールできるものは脆弱性のみ
  • 洗い出しが必要
• 脅威のモデル化プロセス
  • セキュリティPoCを任命する
  • データフローテーブルに入力する
  • 脅威のモデル化セッションを実行する
    • 守るべきものの洗い出し
  • 脆弱性をドキュメント化する
    • STRIDE （さまざまな脅威カテゴリを覚える手がかりとなる）
      • Spoofing (なりすまし)
      • Tampering (改ざん)
      • Repudiation (否認)
      • Information disclosure (情報漏えい)
      • Denial of service (サービス拒否)
      • Elevation of privilege (権限の昇格))
    • MITER ATT&CK：脅威分析の手法の一つ。戦術ベースのアプローチ。
• 全体的なセキュリティを評価する
  • AWS Trusted Advisor
    • AWSアカウントの契約によってサポートされるセキュリティチェックの範囲が変わる

モジュール04: アプリケーションセキュリティ

EC2のセキュリティについて学ぶ

• EC2へのログイン
  • キーペアでSSH
  • ディレクトリドメイン (Active Directory または LDAP) に参加後、フェデレーションアクセスを有効にして、AWS Single Sign-On (SSO) を使用する。
• インスタンスメタデータサービス（IMDS)
  • アプリケーションに頻繁にローテーションされる一時的な認証情報へのアクセスを提供
  • OS上から「169.254.169.254」にHTTPSリクエスト
  • バージョン2を使うことがベストプラクティス
• Amazonマシーンイメージ
  • 最新版AMIを使う
  • カスタムAMI＋ブートストラップ＝EC2フリート
  • マーケットプレイスAMIはAWSによって検証済
  • コミュニティAMIはセキュリティ的に使わない
  • AMIの保護
    • 安全でないアプリを無効化する
    • アクセス可能な部分を最小化する
    • システムとログデータを保護する
    • EC2 ImageEC2 Image Builderを使用して、イメージを最新かつ安全に保つ
• Amazon Inspector
  • 現在はバージョン2になって性能良くなった
    • コンテナ環境に対してスキャンできる
    • SSMエージェントでできる
    • ダッシュボードで脆弱性が簡単に確認できる
  • 使用方法
    • SSMエージェントインストール
    • EC2にIAMロールを付与
    • スキャンするEC2にタグ付け
    • 実行する評価を定義し、スケジュールを設定
• Systems Manager
  • 一言で言うのは難しいくらいたくさんの機能がある
  • 主にEC2のアプリケーションやOSのセキュリティと強化を一元管理
  • 使用方法
    • IAMロールを持つインスタンスプロファイルを作成
    • EC2にIAMロールをアタッチ
    • エージェントをインストール（今はほとんどのAMIにインストールされている）
  • 機能紹介
    • インベントリ（EC2上にどんなミドルウェアがインストールされているか確認）
    • SessionManager
    • コンプライアンス
    • 自動化(オートメーション)
    • その他たくさんの機能がある
• InspectorとSystems Managerを一緒に使う
  • パッチマネージャーはOSごとに事前定義されたベースラインを適用する
  • Inspectorでスキャンした内容とパッチマネージャーで修正する内容に互換性はない
  • FutureVulsで直接SSMを利用してパッチ適用できる

ラボ02: AWS System ManagerとAmazon Inspectorを使用する

Systems Managerを利用したパッチの自動配信、Inspectorを利用したセキュリティ評価を体験

2日目

モジュール05: データセキュリティ

データ保護について学ぶ

• データ保護戦略の脅威
  • 情報漏洩
  • データの整合性の侵害
  • 偶発的な削除
  • システム・SW・HWの可用性
• これらの脅威について対策が必要
• 保管中のデータを保護：S3
  • 暗号化基礎の確認
  • 鍵とアルゴリズムでデータを保護
  • エンベロープ暗号化：対称データキーを別のキーであるKMS Keyを使って暗号化
• S3の鍵の種類
  • SSE-C：お客様がキーの制御を維持
  • SSE-S3：AWSがキーを管理
    • 暗号化されたデータとキーを異なるホストに保存
  • SSE-KMS：AWSがキーを管理
    • 追加保護のためエンベロープ暗号化を使用
    • リソースポリシー（KeyPolicy）を持つ
• S3リソース保護の確認
  • オブジェクトACL
  • バケットACL
  • バケットポリシー
  • IAMポリシー
  • バージョニング
    • 削除されたオブジェクトの取得を容易にする
    • ライフサイクルポリシーでコスト削減
  • オブジェクトロック
    • WORMモデル（書き込み1回のみ）を使用してオブジェクトを保存
    • 2つの保持モードを容易
      • ガバナンス（切り戻し可能）
      • コンプライアンス（どのユーザーも無効化できない）
  • ブロックパブリックアクセス
    • ACLで公開してても保護してくれる
    • クロスアカウントアクセスもブロック
    • 一番強い
  • クロスリージョンレプリケーション
    • コンプライアンス要件・災害要件・過失又は悪意によるデータの削除
    • 現在はセイムリージョンもOK、複数のリージョンにレプリケーションもOK
  • S3 Access Analyzer
    • S3専用のIAM Access Analyzer
  • S3 Access Ponts
    • 登場前：1つのエンドポイントで複数のステークホルダーがアクセス
      • バケットポリシーが煩雑に
    • 登場後：複数のエンドポイントとアクセスポイントポリシーで複数のステークホルダーがアクセスしやすくなった
      • バケットポリシーに手を加えなくて良い○
• RDSの保護
  • 転送中
    • TLSとネイティブ暗号化クライアントを使用
    • RDSがアクセス認証を処理
  • 保管中
    • AWS-256暗号化アルゴリズムを使用
    • DB作成時に暗号化を有効にすることが必要
    • 特定のDBエンジンでTDEをサポート
• DynamoDB
  • APIの中で細かい制御をできる
  • RDS同様、転送中・保管中の暗号化ができる
  • S3のSSE-KMSとは異なりテーブルキーが存在する（※現在はS3にも同様の仕組みあり）
    • 1回KMS呼び出したらテーブルキーが作成される
    • データキーはそのテーブルキーを使用して暗号化をする
    • KMSからの呼び出し回数が減り、コストが削減する
  • クロスリージョン暗号化
• S3 Glacier
  • ボールトロック
    • ポリシーは1度設定すると変更できない

モジュール06: セキュリティに関する考慮事項: ハイブリッド環境

VPCのさまざままセキュリティ機能について学ぶ

• VPCのセキュリティ
  • サブネット
    • パブリックサブネット：パブリックIPアドレス経由で外部と通信
    • プライベートサブネット：インターネットに間接的にアクセス
    • 保護されたサブネット：規制対象ワークロード用、インターネットアクセスなし
  • セキュリティグループ：ステートフル
  • ネットワークACL：ステートレス
  • VPCトラフィックミラーリング
    • ネットワークとセキュリティの異常や脅威を検出
    • トラフィックを抽出し、WireSharkなどのツールに転送できる
    • VPCフローログではパケットの中身まで見れない
• 侵害されたインスタンスへの対処
  • インスタンス情報を収集・タグを付与
  • AutoScaling・ALBからデタッチ
  • 隔離用のSGを作成し、移動
  • 侵害されたインスタンスのAMIをとる
  • フォレンジック用インスタンスを取得したAMIで作成
• VPCピア接続
• VPCエンドポイント
  • インターネット経由せずにAWSリソースに接続できる
  • PrivatelinkによりAWSに閉じたサービス利用ができる
  • サービス利用側→サービス提供側からの通信のみ
  • S3のインターフェイスエンドポイント
    • オンプレミスや別リージョンからのエンドポイント接続を可能
• ELB
  • データ転送中
  • 単一の通信先と最前線の防御
  • HTTPSにTLSを使用したエンドツーエンドの暗号化
  • ユーザ認証（ALBのみ）
• AWS Certification Manager
  • パブリック証明書とプライベート証明書の両方を管理する
  • 自分達のデバイスに証明書を付与したい場合はプライベート証明書使うときあるが、コストがかなりかかるため、あんまり使用しない

モジュール07: AWSでのログの監視と収集

モニタリングと、ログ記録戦略の重要性について学ぶ

• セキュリティをモニタリングする
  • パフォーマンス指標は
  • 測定する方法は
  • 閾値は何か
  • どうエスカレーションするのか？
• CloudWatch
  • たくさんの機能がある
  • ベーシックな使い方はイベントとアラームを組み込んで通知を自動的に変更する
• Config
  • AWSの各リソースの変更をモニタリング
  • リソースタイムラインで過去のイベントを追うことができる
  • 非準拠のものに修復アクションを実行できる
  • 修復アクションの正体はSSMドキュメント（オートメーションを呼び出している）
  • 修復アクションは自分でも作れる
  • Config自体が修復を行うわけでない
  • Configのコンフォーマンスパック
    • AWSリソースのコンプラインスを大規模に管理
• Macie
  • 機密データを識別
  • 主にS3に保存されたデータ
• ログ記録戦略
  • 全てのログを容易にアクセスできる安全で一元管理されたリポジトリに保存する
  • 全てのログをすぐに分析しない場合でも、できるだけ多くログを記録する
  • ログをできるだけ長い間保存して、長期的な分析に利用する
• CloudWatchLogs
  • エージェントをインストールしロールをアタッチする
  • メトリクスフィルターを使用してモニタリング
  • ログデータにアクセスする
• CloudWatchLogs Insights
• VPCフローログ
  • REJECTだけをキャプチャしてトラブルシューティングに役立てることもできる
• S3サーバーアクセスログ
  • CloudTrailでのS3ログの方が監査目的としては良い
• ELBのアクセスログ

ラボ03: AWS Configを使用したモニタリングと応答

AWS Configを用いて、セキュリティ違反を自動修復する方法を体験

モジュール08: AWSでのログの処理

ログを処理するさまざまな方法を学ぶ

• Amazon Kinesis
  • ログの取り込み
    • Data Streams
      • カスタマイズしたい、かつリアルタイム性を求める
    • Data Firehose
      • カスタマイズ不要でシンプルに使用したい、最低でも取り込みに60秒かかる
      • データの生成
        • HTTPS PUTコマンド
        • Kinesis Producer Library
        • Kiesis エージェント
  • ログの解析
    • Data Analytics
• Athena
  • S3内のデータをSQLで分析できるクエリサービスを提供

ラボ04: Amazon EC2、Kinesis Data Firehose、Amazon S3、Athenaを使用したウェブサーバー

ウェブサーバーのログ分析を、各サービスを使って体験

モジュール09: セキュリティに関する考慮事項:ハイブリッド環境

オンプレミスとの接続に使用するサービスについて学ぶ

• AWSサイト間VPN接続
  • AWS側にVGW、企業側にカスタマーゲートウェイ
• AWSClientVPN接続
  • Open VPNの仕組みで接続
  • AWS側にはクライアントVPNエンドポイント
• AWS DirectConnect
  • 専用線
  • DirectConnect Gatewayでは10拠点まで
• AWS Transit Gateway
  • 各接続のハブになる
• AWS VPN CloudHub
  • サービス名ではなく、使い方
  • クラウドを経由して、別の環境に接続する

3日目

モジュール10: リージョン外の保護

エッジローケーションで、データや環境を保護する仕組みを学ぶ

• サービス拒否の脅威（DoS・DDoS）
  • 低レイヤー
    • UDPリフレクション・SYNフラッド・ICMPフラッド
  • 高レイヤー
    • DNSフラッド・スローロリス・HTTPフラッド
  • DDoS緩和のアプローチ
    • スケールして攻撃を吸収する
• AWSでのDDoS耐性
  • エッジでの保護
    • Amazon Route53
      • SLA100％
      • 1つホストゾーンで4つネームサーバが登録される（委任セットと呼ばれる）
      • エニーキャストストライピングによりネームサーバを分散
      • シャッフルシャーディングによる攻撃を分離
    • AWS WAF
      • まずはAWS提供のマネージドルールを設定
      • 必要に応じてカスタムルールを設定
      • ウェブACLを使って、上記の様々なルールを組み合わせる
      • 各AWSリソースにウェブACLを適用する
      • CloudFrontにはバージニアリージョンのウェブACLしか適用できないから注意
      • セキュリティオートメーションでリアルタイムで不正リクエストをブロックする
    • Amazon CloudFront
      • オリジンサーバーでのアクセス制限方法
        • S3バケットのOAC（以前はOAI）
        • S3 URLでなくCloudFront URLでオブジェクトにアクセスする必要がある
        • CloudFrontトラフィックのみを許可するようオリジンインスタンスのセキュリティグループを更新する
      • エッジでのアクセス制限
        • 署名付きURLや署名付きCookieを使用する
      • 機密データのフィールドレベル暗号化を行う
      • CloudFrontのアクセスログを使う
    • AWS Shield
      • Standard：デフォルトで有効化
      • Advanced：Standardにはない点
        • 特定サービスに対するDDoS攻撃からの保護強化
        • 24時間年中無休のDDoDレスポンスチーム（SRT）
        • DDoSスパイクに対するコスト保護
        • リアルタイムレポートの利用
    • AWS FireWall Manager
      • 複数のアカウントのWAF管理およびメンテナンスタスクを簡素化する
      • AWS Organizationsの有効化が必要

モジュール11: セキュリティに関する考慮事項: サーバーレス環境

サーバーレスサービスのセキュリティ機能について学ぶ

• Cognito
  • ユーザープールの保護機能
    • 組み込み可能なログインウェブUIを提供
    • 漏洩した認証情報のチェック
    • 電話やEメールによる検証
    • アダプティブ認証：不正なサインインをブロック、またはリスクレベル上昇に応じて2段階を要求する
  • IDプール
    • STSにAssumeRoleWithWebIdentity API コールを行う
• APIGateway
  • スロットリングを使用してトラフィックのスパイクから保護
  • APIエンドポイントのアクセスコントロール
  • HTTPSサポート・DDoS攻撃の緩和
• Lambda
  • Lambdaはスケーリングするため、なるべくVPCの中に置かないほうがいい
  • リソースベースのポリシー
  • 関数をモニタリングし、ログに記録する
  • Lambda Function URLs（APIGatewayなしでHTTPS経由で実行できる）

モジュール12: 脅威検出と調査

Amazon GuardDuty、AWS Security Hub、Amazon Detectiveの概要について学ぶ

• Amazon GuardDuty
  • 機械学習を使用して脅威や異常をLow・HIgh・Middleで検出
  • 脅威インテリジェンスによって疑わしい攻撃者を特定
  • 使い方：有効化のみ
  • ユースケース：予防処置の自動化（CloudWatch→CloudWatch Events→Lambda）
• AWS Security Hub
  • 各種AWSセキュリティサービスと統合
  • セキュリティとコンプライアンスの要件に基づいて結果を収集、優先順位付け
  • 使い方：有効化のみ
  • AWS基礎セキュリティのベストプラクティスの有効化でOK
  • Configとの違い
    • チェックした項目の重要度を出してくれる
    • ステータス管理できる
  • ユースケース：脅威対応の自動化（CloudWatch Events→SNS ・Lambda）
    • 全項目自動対応できる訳ではない
• Amazon Detective
  • セキュリティの検出結果の調査と分析
  • VPC Flow Logs・CloudTrail・GuardDuty Findings(検出結果)を自動で取り込む
  • 関連性をわかりやすいグラフやマップで視覚化
  • 攻撃者の行動を辿ることができる

モジュール13: AWS での機密情報管理

AWS KMS、AWS CloudHSM、AWS Secrets Managerについて学ぶ

• キー管理の課題
  • 暗号化されたキーの量とともに管理オーバーヘッドが増加する
• AWS KMS
  • エンベロープ暗号化
    • KMSキーでデータキーを暗号化してデータと一緒に保存する
  • KMSキーの機能
    • 一意のエイリアスと説明をつけたマスターキーを作成する
    • 自動的にローテーション
    • キーを無効化または削除する
  • キーの保護
    • リソースベースのポリシー
    • 許可(Grants)：一時的なアクセス許可
  • キーのインポート
    • 独自のキーを使用したい場合（よっぽどなことがない限り使わない）
  • キーのローテーション
    • カスタマーマスターキーにはキーIDとバッキングキーを保持
    • ローテーションの際に新しいバッキングキーを払い出し、使用する
    • 古いバッキングキーも復号のために保持される
• AWS CloudHSM
  • 不正開封防止が備わったハードウェアデバイスを使用してキーを安全に生成して保存
  • カスタムキーストア
    • AWS内のシングルテナントに鍵が保存される
    • コンプライアンスがCloudHSMと同じ（FIPS140-3 レベル3）
    • どのようなシステムがシステム用件としてCloudHSMやカスタムキーストアを使うことがあるのでしょうか？
• AWS Secrets Manager
  • 機密情報を安全な場所に保存
  • 安全にローテーションできる
  • パラメータストアとの違い
    • 自動シークレットローテーション
    • 組み込みパスワードジェネレーターがある
    • 追加コストがかかる
    • 最大64kbの値を保存できる

ラボ05: AWS KMSを使用する

KMSの設定、KMSを利用した暗号化を体験

モジュール14: 自動化と設計によるセキュリティ

AWS CloudFormation、AWS Service Catalogについて学ぶ

• CloudFormation
  • セキュリティのベストプラクティス
    • IAMでのアクセス管理
    • 認証情報は動的リファレンスを使用
    • ドリフト検出を使用して設定変更を検出する
    • スタックの削除保護、DeletionPolicy、スタックポリシーを使用して不要な更新や削除を回避する
• Service Catalog
  • セキュリティのベストプラクティス
    • IAMロール使用してカタログにアクセスできるユーザーを制御
    • カタログ管理者が製品を管理しポートフォリオに整理する
    • エンドユーザーがアクセス権限が付与されている製品を起動する

ラボ06: AWS Service Catalogを使用する

AWS Service Catalogのポートフォリオ作成、起動制約の追加、製品の起動を体験

モジュール15: AWS のアカウント管理とプロビジョニング

AWS Organizations、AWS Control Towerについて学ぶ

• 複数アカウントでリソース分離することがベストプラクティス。
• AWS Organizations
  • 使い方
    • 組織の作成
    • 組織単位の作成
    • AWSアカウントを追加または作成する
    • SCPを作成して割り当てる（1つのOUに最大5つまで）
      • ルートOUにはSCPのFullAWSAccessがデフォルトでアタッチされている
• AWS Control Tower
  • ランディングゾーンのベストプラクティスに基づいて、複数アカウントのセットアップを自動化
  • パッケージ化されたガードレールを適用して、継続的なガバナンスを提供
• どちらが適しているか？
  • はじめはAWS Control Tower使ってみる。
  • よりカスタマイズを行いたい場合はAWS Organizationsを使う。

ラボ07: ADFSを使用したAWSフェデレーション認証

Active DirectoryユーザをAWSマネジメントコンソールにアクセスできるようにするプロセスを体験

受講して良かった点

• 3日間どっぷりとセキュリティに浸かることができた。
• 基礎的なセキュリティに関する考え方からおさらいすることができた。
• 疑問に感じたことをその場ですぐに質問することができた。
• ラボを通じて、各AWSサービスの操作方法を知ることができた。

最後に

今回は、「Security Engineering on AWS」でどんなことが学べるのかお伝えしました。

受講前は各AWSサービスについて何となく理解しているけど、セキュリティ対策にどう落とし込めばいいのだろうと疑問に思っていました。 受講後にこの疑問を解決できたのが良かったです！

セキュリティ要件の策定や設計担当者で同じように悩んでいる方は、1度受講することをおすすめします！ こちらよりトレーニングを申し込み頂けます。

AWSトレーニングサービス | クラスメソッド

最後までお読みいただきありがとうございました！ この記事がどなたかのお役に立てれば幸いです。

以上、おつまみ（＠AWS11077）でした！