各セキュリティサービスの特徴が理解できる【Security Engineering on AWS】を受講してみた

皆さんこんにちは、AWS 事業本部オペレーション部に2023年11月より異動した清水です。

まだまだ初学者の身であり、AWS のセキュリティサービスについて学習するべく、「Security Engineering on AWS」を受講してきました！

以下に学習した内容を記載しましたので、本コースの受講をお考え中の方へ、お役に立てば幸いです。

AWS認定トレーニングとは？

以下のブログに、弊社AWS認定トレーニング講師の平野のほうで執筆した各トレーニングの詳細が記載されています。

私が今回受講したのは、以下の図の赤枠に入るコースになります。AWS を利用して、より高度なセキュリティマネジメントを実施する方法を学びたい方におススメのコースになります。

3日間のコースで、AWSを利用する上でのセキュリティの考え方、AWSのセキュリティサービスについて学ぶことができます。受講した理由に関しては、以下の二点です。

1. AWS の様々なセキュリティサービスを理解し、今後メンバーズご利用のお客様に対して、テクニカルサポートを行う上で業務に役立てたい
2. AWS Certified Security 認定を取得するため

事前準備

お申込みすると以下のようなメールが届き、事前にこのような前提知識があるうえでトレーニングが行われるといった説明が記載されています。

知識レベル

1. IT セキュリティプラクティスおよびインフラストラクチャの概念の実務的知識
2. クラウドコンピューティングの概念に関する知識があること
3. Architecting on AWS クラスルームトレーニングの受講

無料デジタルトレーニング（事前受講推奨）

1. AWS Security Fundamentals (Second Edition) (Japanese)
   1. AWSにおける網羅的なセキュリティ基礎の学習。（所要時間2時間）
2. Getting Started with AWS Security, Identity, and Compliance (Japanese) (日本語吹き替え版)
   1. AWS Security Fundamentals (Second Edition)の次の段階のセキュリティ。具体的なアイデンティティ管理やインシデント対応など（所要時間3時間）

１日目

モジュール１：セキュリティの概要

• AWS の責任範囲とお客様の責任範囲
  • 利用する AWS サービスにより少し異なってくる
• MSO 責任モデルについて
  • 誰がどの範囲の責任を担保するのか【AWS - MSO/MSP （情シス部門など） - 事業部門】
• クラウドにおけるセキュリティ原則
  • 人的リソースを費やしたり、高額な製品の購入等とセキュリティをトレードオフしなくていい
• 脅威モデリングプロセス

モジュール２：AWSにおけるアクセスと権限付与

【AWS IAM】

• IAM ユーザー（ユーザーが利用）
• IAM ロール（AWSサービスへの割り当て用。例：EC2インスタンス→S3アクセスする際の権限設定で利用）

API エンドポイント

• API エンドポイントへのアクセスと、署名によるAPIの保護について
• AWS Security Token Serviceのユースケース
  • 短期間のセキュリティ認証情報を利用
  • AWS STS APIコール

ポリシー

ルール

• 許可も否定も設定していない場合は、デフォルトで全て拒否
• 許可と拒否の競合がある場合は、拒否が優先
• 明示的な拒否と暗黙的な拒否の意味の違い
  • 単体のポリシーでは比較すると同じ意味となるものでも、他のポリシーと組み合わせると意味が変わる

タイプ

• リソースベースのポリシー
  • S3バケットポリシーなど
• IAM Permissions boundary
  • 管理者が必要以上に権限を拡大しないように、Permissions boundaryの付与された範囲でしかIAMの操作ができないようにするもの

• セッションポリシー
  • 普段より権限を制御したいときなど。今から5分間だけ一時的にアクセス許可をするといったようなケースに利用（Assume Role）
• アイデンティティベースのポリシー
  • IAM ユーザー・IAM ロールなど
  • 管理ポリシーを使う。インラインポリシーは特殊な要件だった場合に利用するのが良い

評価論理

1. 明示的な拒否
2. リソースベースのポリシー
3. Permissions boundary
4. セッションポリシー
5. アイデンティティベースのポリシー

【AWS CloudTrail】

• ログは S3に保存する設定を、先に有効化。それをしないと90日でログが消える
• MFA Deleteを有効にする
• ログ統合
• ログファイルの整合性

IAMアクセスの可視化

• IAM Access Analyzer（無料のため、とりあえず設定して利用してみるのがオススメ）
• 認証情報レポート

ラボ１：アイデンティティ＆リソースベースポリシー

1. ポリシーを利用して権限を定義
2. 権限管理のために、アイデンティティベースとリソースベースのポリシーの使用
3. IAMアクセス許可の境界を使用して、IAMロールにアクセス許可の上限を設定

モジュール３：AWSにおけるアカウント管理とプロビジョニング

【AWS Organizations】

-複数のアカウントの管理を目的

• ログを簡単に集約
• 監査データの集約
• ファイヤーウォールを一元管理

ポリシーの評価論理

1. 明示的な拒否
2. AWS Organizations
3. リソースベースのポリシー
4. Permissions boundary
5. セッションポリシー
6. アイデンティティベースのポリシー

【AWS Control Tower】

-複数のすべてのAWSアカウントに設定すべき内容を、AWSのベストプラクティスに沿って自動化

• 必須のガードレールが、デフォルトで有効化される

２日目

アイデンティティフェデレーション

• 1か所で認証情報を管理
• AWSアカウント毎に、認証情報を管理する必要をなくす
• Assume RoleのAPIを実行

【IAM Identity Center（AWS Single Sign-Onの後継）】

• Active Directoryと連携
• ただし、必ずしもこれを使う必要はない
• 他の3rd Party製の製品を使ってもいい

【Amazon Cognito】

-Webアプリ・モバイルアプリのアクセス制御

log in→Web idps→Amazon Cognito Identity pools→AWS STS

• ユーザープール
• IDプール（外部の認証基盤と連携）
• アダプティブ認証（MFAを必須にする設定は、常に行うのが良い）

モジュール４：AWSにおけるキーとシークレットの管理

【AWS KMS】

-鍵の保管と管理・データ暗号化

• テナンシー：マルチテナント
• 料金：APIコールとキーごと
• リージョン選択は出来ない
•  キー（インポート可能）
  1. 対称キー
  2. 非対称キー
  3. HMACキー
• エンベロープ暗号化を使用した2階層のキー階層
  • ポリシー：リソースベースの権限
  • グラント：一時的な権限
•  一意のエイリアスと説明を使用してKMSキーを作成→自動的にローテーション
• 使用ポリシー
  • キーIDとバッキングキー
  • マルチリージョンキー（リージョンが変わると鍵が使えなくなる）
• CloudTailで使用状況を監査できる

【AWS CloudHSM】

-暗号化した鍵の管理・生成のみ。KMSのようにうまくエンベロープ暗号化を、してくれるわけではない（仕組化されていない）

• テナンシー：シングルテナント
• 料金：１時間ごと
• リージョン選択可能
• 厳密なセキュリティ要件として、シングルテナントでFIPS140-2 レベル３の認定すべてを取得したHSMに保管する必要がある場合に利用
  • 基本はKMSを利用したほうが、ユーザーとしては容易に利用が可能

【AWS Certificate Manager】

-パブリック証明書、プライベート証明書の両方を、単一インターフェイスで管理

• 外部の認証局で証明書を発行した場合は、自動更新は出来ない

【AWS Secrets Manager】

-暗号化に使う鍵以外の機密情報を管理（データベース認証情報など）

AWS Lambda ⇔ AWS Secrets Manager ⇔ RDS

• KMSだと暗号化に使う鍵しか管理できないため、こちらを利用
• 内臓パスワードジェネレータ
• シークレットローテーションの自動化
• クロスアカウントアクセス
• KMSで暗号化された値
• 最大64KB sizeのシークレットを保存

ラボ 3: AWS KMS を使用して Secrets Manager シークレットを暗号化する

1. AWS KMSキーの作成
2. Secret ManagerシークレットをAWS KMSキーで暗号化
3. Secret Managerシークレットのローテーションの設定
4. 暗号化されたシークレットを利用し、RDSに接続

モジュール５：データセキュリティ

【Amazon S3】

• 保存データは、特別な要件がなければデフォルトの暗号化を使う
  •  SSE（暗号化種類）
    1. SSE-S3（デフォルト・AWSによって鍵の管理をする）
    2. SSE-C（鍵の管理をお客様で行う）
    3. SSE-KMS（KMSによるサーバー側の暗号化）

• オブジェクトロックのON（保持期間の短縮は出来ない、その間上書きも削除もできない）
  1. ガバナンス保存モード
  2. コンプライアンス保存モード（こちらの方が制御が厳しい）
• バージョンニングの有効
  • UPロードするたびに、新しいバージョンを作成
  • 上書きされても、削除されず昔のオブジェクトへ戻すことが可能
• 最小権限アクセス

保存されているデータをスキャン（Amazon Macie)

• 個人を特定できる情報などの機密データを認識
• S3に保存されているデータのをスキャンし、リソースポリシーを監視
  1. ジョブのスケジュールを設定
  2. S3バケットを選択
  3. 調査結果の確認

ACL

• アクセス制御が細かくできないため、ACLは現在ではあまり使われなくなっている
  1. バケットポリシー（リソースベース）
  2. IAMポリシー（アイデンティティベース）

ブロックパブリックアクセス

1. アカウント、リソース間で設定が異なる場合、最も制限の厳しい設定が適用される
2. 他のアクセス制御を上書きする（このため積極的に使うといい）

バケットレプリケーション

• クロスリージョンで、バケットと個々のオブジェクトのレプリケーション

【Amazon RDS】

• データベースへのアクセスを制御
  1. パスワード認証
  2. Kerberos認証
  3. IAMデータベース認証
• クロスリージョン暗号化
  1. リードレプリカとDBスナップショット
  2. データは暗号化されたまま
  3. リージョン数は制限なし

【Amazon DynamoDB】

• AWS KMSへ毎回キーの複合化をすると費用がかさむため、中間のテーブルキーを利用する（S3の場合はバケットキー）
• クロスリージョン暗号化
  1. グローバルテーブル
  2. データは暗号化されたまま
  3. リージョン数は2つ以上

【Amazon EBS】

• メディアの廃棄
  • NISTO800-88
  • DOD5220.22-M

【Amazon S3 Glacier】

-保存料金がS3より安価。その代わりにデータの取り出しに時間がかかる

• ボールトロック
  • ロック後はポリシー変更不可

ラボ ４: Amazon S3のデータセキュリティ

1. S3バケットで使用するAWS KMSキーの作成
2. S3バケット内のデータをAWS KMSキーで暗号化
3. S3バケットポリシーを作成、オブジェクトに暗号化を適用
4. S3バケットの暗号化されたデータを別のリージョンへ複製
5. Macieを使用し、S3オブジェクト内の個人情報を識別

モジュール６：インフラストラクチャとエッジ保護

【AWS Network Firewall】

-ドメイン名を指定したフィルタリングが可能

• Network Firewall専用のサブネットを作成する

セキュリティグループ（メイン利用) ・ACL（補完利用）

• ステートフルとステートレス
• 許可のみルールと許可・拒否のルール

AWSマネージド脅威シグネチャ

• 無料で利用可能
• 脅威を検知し既知の脆弱性に対する攻撃をブロック

VPCエンドポイント

• VPC内から、色んなAWSのサービスを利用する際に利用
• サブネットにアタッチ
• サービスごとにVPCエンドポイントを作成する必要がある
  • NAT gateway経由のほうが料金が安い時も。コストがVPCエンドポイントは高い場合が多々ある

ゲートウェイエンドポイント

• 無料！
• S3とDynamoDBへの接続のみサポート
  • それ以外のサービスはインターフェイスエンドポイントを利用

【Amazon Elastic Load Balancing】

-負荷分散・ヘルスチェック・スケーリング -複数のタイプのロードバランサー

1. NLB（静的なIPアドレスを利用したい場合など）
2. ALB（スティッキーセッション、ユーザー認証のサポート）
3. GLB（あまり利用することがない）
4. CLB（昔からあるロードバランサー、ほぼ利用することが現在はない）

• サーバー証明書を設定できる
  • TLSオフロードの設定

【Amazon CloudFront】

-エッジロケーション側にCloudFrontが存在

•  フィールドレベルの暗号化
  • 入力フォームに入力された項目のデータを、ストレージに送信する時点で暗号化される
• アクセス制御
  • S3バケットにはOAI→OACを使用（現在は、OACを利用するのが鉄則！）

【Amazon Route53】

• ホストゾーンの設定が可能
  • 委任セット
• シャッフルシャーディングによる攻撃の隔離
  • １顧客あたり４つ/2048台

【AWS WAF】

-Webアプリを狙った悪意あるリクエストを検出、ブロック

• 許可リスト、拒否リストでルールを記述
• ルールグループ
  1. 自分で作成できるカスタムルール
  2. AWSマネージドルール
• ブロッキングとフィルタリング

DDoS攻撃

• 攻撃対策の進化
  1. オンプレミス
  2. SaaS
  3. クラウドファースト（AWS Shieldがある）

【AWS Shield】

• ２つのプラン
  1. Standard（無料）
  2. Advanced（有料　3000ドル/月の年間契約、WAFとFirewall Managerの利用費も含まれている）
     1. DDoSレスポンスチームが年中無休で対応（ただし英語のみ）
     2. レイヤ７での高度な攻撃の場合、攻撃に対するサポートを受けることができる
     3. WAFの記述のアドバイスをもらえる
• 保護グループの使用が可能
  • 複数の保護対象リソースを１つのユニットで扱う

3日目

ラボ５：AWS WAFを使って悪意あるトラフィックを軽減する

1. AWS WAF CloudFormation テンプレート用のセキュリティオートメーションによってデプロイされたリソースを特定
2. AWS WAF のセキュリティオートメーションを使用して、サービス拒否攻撃や SQL インジェクション攻撃を軽減
3. AWS WAF のセキュリティオートメーション構成が意図したとおりに動作することを確認

モジュール７：AWSにおけるログのモニタリングと収集

ログ

クラウドの考え方

1. 一元的な場所に保存
2. すべてログに記録
3. ログはできるだけ長く保管

出力先：ログの内容により異なる

• S3
  • ELBアクセスログ
  • S3サーバーアクセスログ（コスト安い、情報少ない、ざっくりログを見たいとき）
  • S3バケットアクセスログ（コスト高い、情報が多い、詳細のログを見たいとき）
    • データ系のAPIは、デフォルトではCloudTrailでは記録されないので設定が必要！
    • CloudTrailでS3にログを保存する設定にしないと、90日で消えるため注意！
• CloudWatch Logs
  • VPCフローログ（通信の中身に関するログは入っていない、トラフィックの記録）
    • アクション：セキュリティグループ or ネットワークACLに基づくトラフィック

【CloudWatchアラーム】

• メトリクスアラーム
• 複合アラーム
• 異常検出バンドのアラーム

【Amazon Kinesis】

-ログの取り込み・ログ分析

• 分単位で取り込み

【Amazon Athena】

-SQLを利用して、S3のデータを分析。サーバーレス

1. データセットの選択 or 作成
2. テーブル作成
3. クエリデータ（クエリ結果は、暗号化される）

【Amazon OpenSearch Service】

-ログ分析をAWSがマネージしてくれる。そのためAthenaより利用費が高い

ラボ６：セキュリティインシデントの監視と対応

1. Linux ベースの EC2 インスタンスに Amazon CloudWatch Logs エージェントのインストール
2. システム認証ログを Amazon CloudWatch Logs に送信
3. VPC フローログを作成して、ネットワークトラフィックをキャプチャ
4. CloudWatch Logs Insights でログを分析

モジュール８：脅威への対応

• クラウドでもインシデントレスポンスのプロセスは変わらない
  • ログとモニタリング
  • 請求とアクティビティ
  • 脅威インテリジェンス
  • AWSアウトリーチ
  • 1回限りの連絡

インシデントレスポンスのフロー

1. コントロールを確立
2. 影響を判断
3. 必要に応じて回復
4. 根本原因の調査
5. 改善

【AWS Security Hub】

-セキュリティ設定のチェック

• セキュリティスコアを100％を目標にするのが、ベストプラクティス
• 内部的にConfigのルールを利用しているので、実際には同じ
• AWSが推奨するようなルールが適用される

脅威検知

【AWS Inspector】

-脆弱性とリスク診断

• CISベンチマーク
• セキュリティのベストプラクティス
• ネットワーク到達性

【AWS GuardDuty】

-攻撃を受けている、実際に問題が起こった後に脅威を検出するまで。

• 偵察
• インスタンスの侵害
• アカウントの侵害
• バケットの侵害
• 全アカウント、全リージョンで有効化するのが推奨

検出した後

【Amazon Detective】

-GuardDutyで検出した結果を分析する

• Amazon Detectiveによるベースラインの作成
  • CloudTrail
  • AWS Config
    • AWS Configコンフォーマンスパック（JSONフォーマット）
      1. マネージドルール（AWSによって定義）
      2. カスタムルール（Lambda関数をユーザーが利用、ユーザーによるメンテナンス）

ラボ ７: インシデント対応

1. 侵害されたインスタンスのメタデータと永続ディスクをキャプチャ。
2. 侵害されたインスタンスのスナップショットを作成。
3. インスタンスを分離し、インスタンスが誤って終了しないようにする。
4. システムログを確認して、違反の疑いがあるかどうかを確認。
5. インスタンス設定を更新して脆弱性を軽減。
6. 自動インシデント対応を作成して、今後同様のインシデントに対応できるように。

終わりに

これまでAWSの各セキュリティサービスの違いがよく理解できておらず、浅い知識でした。

しかし、本コースを受講して同じようなセキュリティサービスでも、比較するとどういった役割の違いがあるのか、コスト面でこちらを利用したほうがいいといったように、ユースケースを教わり実際の使い方のイメージができるようになりました。それから座学で学んだことを、すぐにラボで手を動かせるのもポイントです！

ぜひトレーニングに参加され、浅い知識を深め皆様のビジネスにお役立ていただきたいと思います。