AWS セキュリティの全体像を理解しよう - 初学者が知るべき脅威と対策

AWS セキュリティの全体像を理解しよう 初学者が知るべき脅威と対策 2025/09/11 JAWS-UG 初心者支部#68 残暑のサメとあざらし Security-JAWS コラボ LT 回！ Azara / Norihide Saito

登壇者紹介 名前 所属 Norihide Saito/@a_zara_n 経歴 セキュリティエンジニア。2021年にGMO Flatt Security株式会社に新卒入社。 脆弱性診断業務に従事し、AWSやGCP等のパブリッククラウドを対象としたセ キュリティ診断サービスの立ち上げ、パブリッククラウドと Web のセキュリテ ィを中心にリサーチや講演、発信活動を行う。社外での活動として、セキュリテ ィ・キャンプ などの人材育成事業に従事。また、国内のクラウドセキュリティ コミュニティである Security JAWS での講演やワークショップ開催や CloudSec JP の立ち上げ、各所で講演活動を行う。2025 年に AWS Community builder のセキュリティカテゴリに選出。GMOインターネットグ ループにおいて、クラウドセキュリティ領域におけるエキスパートを選出 2

本日発表内容 AWS 初学者の方が現場で直面するセキュリティ課題について、実践的な対策を中心にお話しします。攻撃者の 視点を理解し、具体的な対策を実装できるようになることを目指します。 📖 Chapter 1: 攻撃者の思考 📖 Chapter 4: AWS サービス活用 クラウドを取り巻く脅威と攻撃者がなぜクラウドを狙 GuardDuty、Security Hub、CloudTrail、Config、 うのか、どのような手法で攻撃するのかを理解しま IAM Identity Centerなど、セキュリティサービスの す。 実践的な活用方法を紹介します。 📖 Chapter 2: 対策の指針 📖 Chapter 5: 継続的な学習 Well-Architected Frameworkに基づくセキュリティ 本日の内容の振り返りと、今後のスキル向上のための 設計の基本原則を学びます。 リソースを提供します。 📖 Chapter 3: 脅威と対策 🗒️ ノート 30分という限られた時間ですが、明日から使える実践的な 5つの主要脅威（認証情報漏洩、フィッシング、設定不 💡知識をお伝えします。 備、サプライチェーン、内部者）への実践的な対策を 説明します。 3

クラウドセキュリティは「知らない」が最大のリスク 攻撃者の手法を知り、適切な対策を実装することで AWS を安全に活用できるようになります 4

あと、スライドの内容は少し難しいかもです... が、スライドを見返したり、実際に手を動かしたりして 理解を深めていただければと思います 5

1. 背景理解 2. 大まかな対策の指針 3. 具体的な脅威と個別対策 4. 具体的な対策と活用 5. まとめと継続的な学習 Chapter 1 クラウドを取り巻く脅威と攻撃者の思考 なぜクラウドが狙われるのか？ 本セクションのトピック 1 クラウド活用の拡大と新たな課題 2 クラウド特性が攻撃者に与えた影響 3 クラウドが直面する具体的脅威 4 責任共有モデル 6

1 クラウド活用の拡大と新たな課題 クラウドは運用負荷軽減や柔軟なスケーリングといった大きなメリットをもたらしましたが、同時に情報資産の 分散や境界の消失といった新たなセキュリティ課題も生み出しました。 ✅ クラウドが解決した従来の課題 ⚠️ クラウドにおける新たな課題 情報資産の分散 ハードウェアを含む 運用負荷の軽減 インフラの即時調達 柔軟なスケーリング ①クラウド活用の拡大と新たな課題 境界の消失 ②クラウド特性が攻撃者に与えた影響 ③クラウドが直面する具体的脅威 責任の複雑化 ④責任共有モデル 7

2 クラウド特性が攻撃者に与えた影響 オンデマンドで即座にリソースを調達できる利便性により、攻撃者は盗んだ認証情報を使って数分でマイニング 環境を構築し、被害者に高額請求を発生させます。また、AWS のような信頼されたドメインからのアクセスは 企業のセキュリティフィルターを通過しやすいため、フィッシングメールの送信元として悪用されるケースが急 増しています。 💡 NIST の定義するクラウド特性 ⚠️ 攻撃者の悪用方法 1 オンデマンド・セルフサービス 2 幅広いネットワークアクセス 3 リソースプーリング 4 迅速な弾力性 5 従量制サービス ①クラウド活用の拡大と新たな課題 ● 認証情報の悪用: EC2/S3 を自由に作成 ● 匿名性の確保: VPN/Tor 経由で追跡困難 ● 信頼性の悪用: AWS ドメインでフィルター回避 ● スケールの悪用: 大規模攻撃を即座に実行 ● コスト転嫁: 被害者が料金を負担 ②クラウド特性が攻撃者に与えた影響 ③クラウドが直面する具体的脅威 ④責任共有モデル 8

2 クラウド特性が攻撃者に与えた影響 クラウドの特性が生み出した「どこからでもアクセス可能」「無限のリソース」「従量課金」という利点は、攻撃 者にとっては「世界中から攻撃可能」「大規模攻撃インフラの即座構築」「コストを被害者に転嫁」という攻撃手 法に変換されます。特に、正規の AWS サービスを悪用した攻撃は検知が困難で、SES によるフィッシングメー ル送信や EC2 を使った攻撃サーバー構築など、クラウドの信頼性を逆手に取った手法が主流となっています。 これらの脅威に対して、次のスライドでは具体的な攻撃パターンとその影響を詳しく見ていきます。 クラウド環境を狙う主要な脅威 Initial Access Data Destruction 漏洩した認証情報で侵⼊ Credential Access さらなる認証情報の窃取 データの破壊・暗号化 AWS環境 顧客データ・機密情報 Resource Hijacking ログ削除・監視回避 Privilege Escalation リソースの不正利⽤ ①クラウド活用の拡大と新たな課題 Defense Evasion 権限昇格・管理者権限取得 ②クラウド特性が攻撃者に与えた影響 ③クラウドが直面する具体的脅威 ④責任共有モデル 9

3 クラウドが直面する具体的脅威 GitHub への認証情報の誤プッシュから始まる侵害が最も頻繁に発生しており、攻撃者は発見から数分で不正利 用を開始します。従来のオンプレミス環境とは異なり、クラウドでは一つの設定ミスが即座に世界中からアクセ ス可能になるという特性が、攻撃の成功率を飛躍的に高めています。 ⚠️ Initial Access 🚨 Credential Access 🔥 Resource Hijacking ● 最初の侵入段階 ● GitHub の認証情報漏洩 ● .env ファイルの公開 ❌ 最頻発 ● 認証情報の窃取 ● メタデータサービス悪用 ● 設定ファイルからの抽出 ❌ 拡散段階 ● リソースの乗っ取り ● 仮想通貨マイニング ● Ransomware 攻撃 ❌ 被害拡大 ※ 具体的な解説はChapter 3 の「具体的な脅威と個別対策」で行います。 👀 重要 ⚠️ 2025年初頭にCodefinger Ransomwareが確認されました。AWS S3のSSE-C機能を悪用し、正規機能のため検知が困難です。 ①クラウド活用の拡大と新たな課題 ②クラウド特性が攻撃者に与えた影響 ③クラウドが直面する具体的脅威 ④責任共有モデル 10

4 クラウドにおけるセキュリティの基本概念 - 責任共有モデル AWS がデータセンターの物理的セキュリティを完璧に管理していても、実際のセキュリティインシデントのほ とんどは利用者の設定ミスに起因しています。クラウドプロバイダーの責任範囲と利用者の責任範囲の境界を正 確に理解することが、セキュリティ事故を防ぐ最初の防衛線となります。 AWSの責任共有モデル 利⽤者の責任：クラウド「内」のセキュリティ 利⽤者のデータ アプリケーション IAM・アクセス管理 OSのパッチ適⽤ ネットワーク設定 暗号化設定 セキュリティグループ 監査・ログ管理 例：S3バケットのアクセス権限設定、EC2インスタンスのセキュリティパッチ、データの暗号化 責任境界 AWSの責任：クラウド「の」セキュリティ 物理的セキュリティ ハードウェア ネットワークインフラ 仮想化レイヤー データセンター ストレージ グローバルインフラ ホストOS 例：S3サービス⾃体のセキュリティ、EC2の仮想化基盤、データセンターの物理的保護 ①クラウド活用の拡大と新たな課題 ②クラウド特性が攻撃者に与えた影響 ③クラウドが直面する具体的脅威 ④責任共有モデル 11

4 クラウドにおけるセキュリティの基本概念 - 責任共有モデル S3 のイレブンナインの耐久性はハードウェア障害からデータを守るものであり、誤削除やランサムウェアから は守りません。RDS が DB パッチを自動適用しても、弱いパスワードやパブリックアクセスの設定ミスは防げ ません。マネージドサービスへの過度な信頼が、セキュリティホールを生み出す原因となっています。 設定値に関する誤解 💬 よくある誤解の例と正しい理解 誤解: 設定は一度だけで OK S3 に関する誤解 正解: 設定は定期的に見直す必要がある 誤解: イレブンナインだからバックアップ不要 誤解: デフォルト設定で十分安全 正解: イレブンナインは耐久性(耐障害性)。 正解: デフォルトは最小限で、サービスに応じた強化が 誤削除やランサムウェアからは守れない 必要 マネージドサービスに関する誤解 IAM に関する誤認識 誤解: マネージドサービスは全て自動で安全になる 誤解: IAM は一度設定すれば安心 正解: マネージドサービスでも 正解: IAM ポリシーは定期的に見直し、最小権限の原 アクセス制御やデータ保護は利用者の責任 則を適用する必要がある データの暗号化 誤解: クラウドは自動で暗号化される 正解: 暗号化はサービスごとに設定が必要 ①クラウド活用の拡大と新たな課題 ②クラウド特性が攻撃者に与えた影響 ③クラウドが直面する具体的脅威 ④責任共有モデル 12

4 クラウドにおけるセキュリティの基本概念 - 責任共有モデル EC2 ではOS のパッチ適用からアプリケーションセキュリティまで全て利用者責任となる一方、Lambda でも コードの脆弱性や環境変数の管理は完全に利用者の責任です。つまり、マネージドレベルが上がってもセキュリ ティ設定の責任は減らないという事実を、以下の表で具体的に示します。 サービス EC2 RDS S3 Lambda AWS 責任範囲 利用者責任範囲 OS パッチ、アプリセキュリティ、IAM 設定、 ハイパーバイザー、物理アクセス ネットワークレベルのアクセス制御 DB ユーザー管理、 DBMS パッチ、バックアップシステム アップデート、 アクセス制御、バックアップの有効化 99.999999999%の耐久性、インフラ バケットポリシー、 データバックアップ、暗号化、アクセス制御 コードセキュリティ、環境変数管理、 ランタイム環境、スケーリング アクセス制御 、スケーリングの設定 DynamoDB データ複製、可用性 ①クラウド活用の拡大と新たな課題 ②クラウド特性が攻撃者に与えた影響 暗号化設定、アクセス制御、バックアップ戦略 ③クラウドが直面する具体的脅威 ④責任共有モデル 13

1. 背景理解 2. 大まかな対策の指針 3. 具体的な脅威と個別対策 4. 具体的な対策と活用 5. まとめと継続的な学習 Chapter 2 大まかな対策の指針 Well-Architected Framework に学ぶセキュリティ設計 本セクションのトピック 1 セキュリティ設計の羅針盤 4 多層防御の実装 2 IAM と 最小権限の原則 5 自動化の重要性 3 すべての行動を記録する 6 データ保護の基本 14

1 セキュリティ設計の羅針盤 - Well-Architected Framework AWS が世界中のインシデント事例から学んだ Well-Architected Framework は、「どうすればいいの？」とい う疑問への具体的な回答を提供します。抽象的な理論ではなく、実際に攻撃を防いだ企業の実践例に基づいたガ イドラインであり、明日からすぐに使える対策が体系的にまとめられています。 Well-Architected Framework セキュリティ設計原則 1. 強固なアイデンティティ基盤 2. トレーサビリティの維持 最⼩権限の原則 MFA必須・IAMロール活⽤ 3. すべての層でのセキュリティ 多層防御の実装 VPC・SG・WAF・暗号化 リアルタイム監視 CloudTrail・監査ログ Well-Architected Framework 4. セキュリティの⾃動化 ⼈為的ミスの排除 Config・Systems Manager 5. データ保護 転送中・保存中の暗号化 機密性レベルで分類 実装優先順位：アイデンティティ管理 → ⾃動化 → 多層防御 → 監視 → データ分類 ①セキュリティ設計の羅針盤 ②IAM と 最小権限の原則 ③すべての行動を記録する ④多層防御の実装 ⑤自動化の重要性 ⑥データ保護の基本 15

1 セキュリティ設計の羅針盤 - Well-Architected Framework Well-Architected Framework の 5 つの設計原則は「最小権限」「トレーサビリティ」「多層防御」「自動化」 「データ保護」というシンプルな言葉に集約されますが、これらを適切に実装することで実際に発生しているセ キュリティインシデントの大半を未然に防ぐことができます。理論的な完璧さより、今すぐ実践できる具体的な 対策を重視したアプローチが、組織を守る最短経路です。 以下の表で本セクションで扱う各設計原則の概要を示します。 💡 設計原則 ✅ 自動化重視 🚨 データ保護 1 最小権限の徹底 2 すべての操作を記録 3 多層防御の実装 💡 基本指針 1 ヒューマンエラー排除 2 IaC による標準化 3 自動修復の実装 1 データ分類の徹底 2 キー管理の一元化 3 機微情報に関してはすべてを暗号 化 ✅ 効率化 ❌ 最重要 🗒️ ノート 💡 このフレームワークは理論ではなく、実際の現場で使える具体的な指針です。 ①セキュリティ設計の羅針盤 ②IAM と 最小権限の原則 ③すべての行動を記録する ④多層防御の実装 ⑤自動化の重要性 ⑥データ保護の基本 16

2 IAM と 最小権限の原則 「面倒だから」という理由で付与された管理者権限が最大のセキュリティホールとなり、一つのアカウント侵害 から仮想通貨マイニング、全データ削除、高額請求といった壊滅的な被害につながります。逆に、必要最小限の 権限のみを付与することで、万が一の侵害時でも被害を局所化できます。 ⚠️ よくある間違い ✅ 正しいアプローチ { { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" } ] "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:DescribeLogGroups", "logs:DescribeLogStreams" ], "Resource": "arn:aws:logs:*:*:log-group:app-*" } ] } 問題点 } ● 管理者権限をすべてのユーザーに付与 ● 「面倒だから」で済ませる危険性 ● 乗っ取られた場合の被害が甚大 利点 ● 必要最小限の権限のみ付与 ● リソース範囲も限定 ● 侵害時の被害を最小化 ❌ 絶対 NG ①セキュリティ設計の羅針盤 ②IAM と 最小権限の原則 ③すべての行動を記録する ④多層防御の実装 ⑤自動化の重要性 ⑥データ保護の基本 17

3 すべての行動を記録する - CloudTrail と Cloud Watch の活用 多くの企業が CloudTrail を有効にしているにもかかわらず、ログに明確な異常が記録されていても数ヶ月間気づ かないという事例が後を絶ちません。ルートアカウントの使用、IAM ポリシーの変更、深夜の大量データアクセ スなど、特定のイベントを監視してアラートを設定することで、攻撃を早期発見し、被害を最小限に抑えられま す。 📖 CloudTrailでの記録 ⚡ 監視と分析 ● すべての API 呼び出しを記録 ● 管理イベントとデータイベント ● 改ざん防止機能 ● 長期保存とアーカイブ ● 異常なアクティビティの検知 ● アクセスパターンの分析 ● インシデント時の迅速調査 ● コンプライアンス対応 💡 基盤ログ ✅ 積極活用 🚨 監視すべきイベント ⚠️ アラート設定例 ● ルートアカウント使用 ● コンソールログイン失敗 ● IAM ポリシー変更 ● S3 バケットの公開設定変更 ● セキュリティグループ変更 ①セキュリティ設計の羅針盤 ②IAM と 最小権限の原則 ③すべての行動を記録する ● 複数地域からの同時ログイン ● 深夜時間帯の大量データアクセス ● 新しい IAM ユーザー作成 ● 暗号化設定の無効化 ● VPC 設定の大幅変更 ④多層防御の実装 ⑤自動化の重要性 ⑥データ保護の基本 18

4 多層防御 - すべての層でセキュリティを適用しよう 中世の城が堀、城壁、天守閣と複数の防御線を持つように、クラウドセキュリティもネットワーク、コンピュー ト、アプリケーション、データの各層で防御を実装します。一つの層が突破されても次の層で攻撃を食い止める ことで、攻撃者に最終目標への到達を困難にし、時間を稼いで対応の機会を得ることができます。 多層防御（Defense in Depth）- 城の防御に例えて DDoS攻撃 ✓ 外堀：ネットワーク境界 CloudFront・Route 53・DDoS Protection 城壁：VPCレベル NACLs・Internet Gateway・NAT Gateway ポートスキャン ⾨：サブネット・セキュリティグループ ✓ Public/Private Subnets・Security Groups・WAF 本丸：アプリケーション層 SQLインジェクション 認証・認可・⼊⼒検証・セッション管理 ✓ 天守閣：データ 暗号化・バックアップ・アクセス制御 防御の原則 • 各層で防御 • 単⼀障害点を作らない ①セキュリティ設計の羅針盤 ②IAM と 最小権限の原則 ③すべての行動を記録する ④多層防御の実装 ⑤自動化の重要性 ⑥データ保護の基本 19

4 多層防御 - すべての層でセキュリティを適用しよう ファイアウォールだけ、WAF だけ、暗号化だけという単一の防御に依存した結果、その一点が突破されて全デ ータを失う事例が繰り返されています。ネットワーク層、コンピュート層、アプリケーション層、データ層それ ぞれに防御を配置することで、攻撃者は全ての層を突破する必要が生じ、侵入の難易度が飛躍的に上昇し、検知 の機会も増えるため、被害を最小限に抑えることができます。 ✅ ネットワーク層 ⚡ コンピュータ層 🚨 アプリ層 📖 データ層 ● VPC 設計 ● Security Groups ● NACLs 💡 境界防御 ● EC2 セキュリティ ● Lambda 権限制御 ● コンテナセキュリティ ✅ 実行環境 ● WAF 設定 ● 認証・認可 ● 入力検証 ❌ アプリ防御 ● 暗号化 ● アクセス制御 ● バックアップ 💡 データ保護 👀 重要 ⚠️ 一つの層が突破されても、他の層で攻撃を食い止める設計が重要です。 ①セキュリティ設計の羅針盤 ②IAM と 最小権限の原則 ③すべての行動を記録する ④多層防御の実装 ⑤自動化の重要性 ⑥データ保護の基本 20

5 自動化による一貫性 「テスト用だから」と作った S3 バケットがパブリック設定のまま放置されて大量の顧客情報が漏洩、「一時的 に」開けたセキュリティグループから侵入されるといった事故が絶えません。Infrastructure as Code で設定 をコード化し、AWS Config で非準拠リソースを自動修正することで、ヒューマンエラーを技術的に防ぐ仕組み を構築できます。 ⚡ Infrastructure as Code (IaC) ✅ 自動修復とコンプライアンス CloudFormation/Terraform で実現すること セキュリティ設定をコード化し、Git でバージョン管理することで、変更履歴の追跡 やレビュープロセスを確立。環境間の一貫性を保ち、ヒューマンエラーを大幅に削 減できます。 実装例 # CloudFormationでS3バケットを安全に設定 Resources: SecureBucket: Type: AWS::S3::Bucket Properties: PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true BucketEncryption: ServerSideEncryptionConfiguration: - ServerSideEncryptionByDefault: SSEAlgorithm: AES256 ①セキュリティ設計の羅針盤 ②IAM と 最小権限の原則 ③すべての行動を記録する AWS Config + Systems Manager の連携 非準拠リソースを Config で検出し、Systems Manager で自動修正。パッチ適用や設定ドリフトの修 正を完全自動化します。 Security Hub での統合管理 複数の AWS アカウントのセキュリティ状態を一元管理 し、CIS や PCI-DSS などの基準に対するコンプライア ンスを自動評価。優先度付けされた修正提案により、限 られたリソースで効率的に対応できます。 🗒️ ノート 💡 自動化は「楽をするため」ではなく「確実性 を高めるため」の手段です。 ④多層防御の実装 ⑤自動化の重要性 ⑥データ保護の基本 21

6 データに関するセキュリティの考え方 暗号化されていないデータベースバックアップが漏洩した場合、顧客情報がそのまま悪用され、GDPR や個人情 報保護法違反で巨額の制裁金を課される可能性があります。S3、RDS、EBS など全てのサービスでデフォルト 暗号化を有効にし、KMS でキーを一元管理することで、万が一のデータ漏洩時でも情報を保護し、法的リスク を回避できます。 転送時の暗号化 🚨 保存時の暗号化 HTTPS/TLS の強制実装 全サービスでデフォルト暗号化 ALB/CloudFront で SSL/TLS を終端し、最新の TLS S3、RDS、DynamoDB、EBS、スナップショット、 1.3 を使用。HTTP から HTTPS への自動リダイレクト AMI など、データを保存する全てのサービスでデフォル を設定し、弱い暗号スイートは完全に無効化します。 ト暗号化を有効化。バケットポリシーで暗号化を強制し ます。 プライベート接続の確保 Site-to-Site VPN や Direct Connect を使用してインタ KMS による一元管理 ーネットを経由しない安全な通信を確立。VPC エンドポ カスタマーマネージドキーを作成し、自動キーローテー イントで AWS サービスへの内部通信を実現します。 ションを設定。キー使用ログを CloudTrail で監査し、不 正なアクセスを即座に検知します。 👀 重要 ⚠️ 暗号化されていないデータは、漏洩時に致命的な被害をもたらします。 ①セキュリティ設計の羅針盤 ②IAM と 最小権限の原則 ③すべての行動を記録する ④多層防御の実装 ⑤自動化の重要性 ⑥データ保護の基本 22

1. 背景理解 2. 大まかな対策の指針 3. 具体的な脅威と個別対策 4. 具体的な対策と活用 5. まとめと継続的な学習 Chapter 3 具体的な脅威と個別対策 現場で遭遇する 5 つの主要脅威への実践的対応 本セクションのトピック 1 5 つの主要脅威の概要 4 設定不備への対策 2 認証情報漏洩への対策 5 サプライチェーン攻撃への対策 3 フィッシング攻撃への対策 6 リソース侵害への対策 23

1 5 つの主要脅威の概要 セキュリティ侵害において、多くの場合以下の 5 つの主要脅威に起因しておりいます。そしてこれらは要因は単 独ではなく連鎖的に発生して被害を拡大させます。一つの脅威への対策不足が、組織全体の崩壊につながる可能 性があることを理解することが重要です。 ①脅威概要 ②認証情報 ③フィッシング ④設定不備 ⑤サプライチェーン ⑥リソース侵害 24

1 5 つの主要脅威の概要 - 具体例 多くの組織が深刻なクラウドセキュリティ侵害を経験し、その大半が複数の脅威が連鎖したものでした。一つの 小さなミスが、組織全体を危機に陥れる時代に私たちは生きています。 ⚠️ 認証情報漏洩 🚨 フィッシング攻撃 🔥 設定不備 ● GitHub 誤プッシュ ● ハードコード ● MFA 突破 ● ソーシャル攻撃 ❌ 最頻発 ● S3 公開設定 ● SG 過度開放 ❌ 巧妙化 ❌ 人的ミス ⚡ サプライチェーン 💬 内部者脅威 ● 依存関係攻撃 ● CI/CD 侵害 ● 権限乱用 ● データ持ち出し ❌ 検知困難 ❌ 信頼悪用 👀 重要 ⚠️ これらの脅威は独立して発生するのではなく、連鎖的に被害が拡大することが多いのが特徴です。 ①脅威概要 ②認証情報 ③フィッシング ④設定不備 ⑤サプライチェーン ⑥リソース侵害 25

2 認証情報漏洩と対策 GitHub に誤ってプッシュされた AWS 認証情報は極めて短時間で悪用され、多くの企業が被害に遭っていま す。「後で直せばいい」という考えが、取り返しのつかない結果を招きます。 ⚠️ 危険なパターン ✅ 安全な実装 # 絶対にやってはいけない例 # 推奨される方法 AWS_ACCESS_KEY = "AKIAIOSFODNN7EXAMPLE" AWS_SECRET_KEY = "wJalrXUtnFEMI/bPxRfiCYzEXAMPLE" # 環境変数またはIAMロールを使用 s3 = boto3.client('s3', aws_access_key_id=AWS_ACCESS_KEY, aws_secret_access_key=AWS_SECRET_KEY ) # または環境変数から読み込み s3 = boto3.client('s3') # 自動的に認証情報検索 import os s3 = boto3.client('s3', aws_access_key_id=os.environ['AWS_ACCESS_KEY_ID'], aws_secret_access_key=os.environ['AWS_SECRET_ACCESS_KEY'] ) 問題点 利点 ● ハードコード ● 履歴に永続 ● 自動悪用 ● 認証情報分離 ● IAM ロール活用 ● 自動ローテーション ①脅威概要 ②認証情報 ③フィッシング ④設定不備 ⑤サプライチェーン ⑥リソース侵害 26

3 フィッシング攻撃

MFA を導入しても安心できません。最新のフィッシング攻撃は MFA コードをリアルタイムで中継し、正規ユー
ザーのセッションを乗っ取ります。技術的対策だけでは防げない、人間の心理を突く攻撃が主流となっていま
す。その際、以下のような設定ミスがあると、攻撃者は容易にクラウド環境を乗っ取りをはじめとした様々な悪
意ある操作を実行できてしまいます。
⚠️ フィッシング後の
⚠️ MFA未設定
⚠️ 過剰な権限
侵害が成立しやすい条件
リスク例
AWS の IAM ユーザーにおける以下のよ ● アカウント完全乗っ取り
うな設定ミスがあると、攻撃者はフィッシ ● フィッシングに弱い
ングを通じて入手した認証情報を用いてク ⚠️ 長時間有効なセッション
ラウド環境に不正アクセスし、様々な悪意
リスク例
ある操作を実行できてしまいます。
リスク例
● アカウント完全乗っ取り
{

"Effect": "Allow",
"Action": "*",
"Resource": "*"

}

1 MFA 未設定の IAM ユーザー
2 過剰な権限を持つ IAM ポリシーをアタッチ
3 長時間有効なセッション

● フィッシング後の長期利用
● 環境における不正操作の継続

● 全リソースへの不正アクセス
● 監査証跡の削除
● 高額請求(リソースの不正利用)

※1. MFA: Multi-Factor Authentication (多要素認証)
※2. OTP(One-Time Password)を用いた MFA が設定されている場合、フィッシングに対しての耐性が弱い
①脅威概要

②認証情報

③フィッシング

④設定不備

⑤サプライチェーン

⑥リソース侵害

27

3 フィッシング攻撃

MFA を導入しても安心できません。最新のフィッシング攻撃は
MFA コードをリアルタイムで中継し、正規ユー
⚠️
フィッシング攻撃の例
ザーのセッションを乗っ取ります。技術的対策だけでは防げない、人間の心理を突く攻撃が主流となっていま
す。その際、以下のような設定ミスがあると、攻撃者は容易にクラウド環境を乗っ取りをはじめとした様々な悪
意ある操作を実行できてしまいます。
⚠️ フィッシング後の
⚠️ MFA未設定
⚠️ 過剰な権限
侵害が成立しやすい条件
リスク例
AWS の IAM ユーザーにおける以下のよ ● アカウント完全乗っ取り
うな設定ミスがあると、攻撃者はフィッシ ● フィッシングに弱い
ングを通じて入手した認証情報を用いてク ⚠️ 長時間有効なセッション
ラウド環境に不正アクセスし、様々な悪意
リスク例
ある操作を実行できてしまいます。
リスク例
● アカウント完全乗っ取り
{

"Effect": "Allow",
"Action": "*",
"Resource": "*"

}

1 MFA 未設定の IAM ユーザー
● フィッシング後の長期利用
● 全リソースへの不正アクセス
出展:
https://www.wiz.io/blog/emerging-phishing-campaign-targeting-aws-accounts
2 過剰な権限を持つ IAM ポリシーをアタッチ
● 環境における不正操作の継続
● 監査証跡の削除
● 高額請求(リソースの不正利用)
3 ⚠️長時間有効なセッション
警告
※1. MFA: Multi-Factor
Authentication (多要素認証)
AWSのIAMユーザーの認証情報を標的にしたフィッシング攻撃は、常に多く報告されており、偽の請求書を用いた例や、
※2. OTP(One-Time偽のセキュリティアラートを用いた例などがあります。そのような通知が来た際は、一度ログインの後に、該当機能を確
Password)を用いた MFA が設定されている場合、フィッシングに対しての耐性が弱い
認しましょう。
①脅威概要

②認証情報

③フィッシング

④設定不備

⑤サプライチェーン

⑥リソース侵害

28

3 フィッシング攻撃への包括的対策 MFA を突破する高度なフィッシング攻撃に対しても、多層防御の実装により被害を最小限に抑制できます。技術 的対策と運用的対策を組み合わせることで、攻撃の成功確率を大幅に低下させることが可能です。 ✅ 技術的対策 ⚡ 運用的対策 FIDO2/WebAuthn の採用 継続的な教育と訓練 フィッシング耐性のある認証により、偽サイトでの認 定期的なフィッシング訓練メールの送信、最新の攻撃 証情報窃取を根本的に防止します。物理セキュリティ 手法の共有、報告文化の醸成により、人的要因による キーやプラットフォーム認証を活用し、攻撃者による 被害を削減します。 中間者攻撃を無力化します。 監視とインシデント対応 セッション管理の強化 CloudTrail による異常ログインの検知、GuardDuty 短時間のセッションタイムアウト、異常検知による自 のアラート即座対応、被害発生時の迅速な権限剥奪に 動ログアウト、デバイス認証の実装により、万が一セ より、攻撃の早期発見と被害拡大防止を実現します。 ッションが奪われても被害を限定的にします。 29

4 設定不備と対策

「テスト用だから」で設定していたものを、本番環境でも同じような設定で公開した S3 バケットから顧客情報
が見えてしまったという事例もあり、設定不備による情報漏洩は依然として多く発生しています。設定ミスを防
ぐには、具体的なリスクを理解し、適切な設定例を学ぶことが重要です。
⚠️ 危険な設定例
✅ 安全な設定例
// S3バケットポリシー - 危険な例

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action":
"s3:GetObject",
"Resource":
"arn:aws:s3:::my-bucket/*"
}
]

Security Group - 危険な例

● Type: HTTP, Port: 80,
Source: 0.0.0.0/0
● Type: SSH, Port: 22,
Source: 0.0.0.0/0
● Type: MySQL, Port: 3306,
Source: 0.0.0.0/0

}

①脅威概要

②認証情報

Security Group - 安全な
例

// S3バケットポリシー - 安全な例

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS":
"arn:aws:iam::123456789012:role/WebRole"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::mybucket/public/*"
}
]
}

③フィッシング

④設定不備

⑤サプライチェーン

● Type: HTTPS,
Port: 443,
Source: ALB-SG
● Type: SSH, Port:
22, Source:
10.0.1.0/24
● Type: MySQL,
Port: 3306,
Source: App-SG

⑥リソース侵害

30

5 サプライチェーン攻撃と対策 npm や PyPI に潜む Credential Stealer は、正規パッケージに偽装して開発者の AWS 認証情報を狙います。 typosquatting による偽パッケージは毎月数千個発見され、インストール直後に環境変数やローカルファイルか ら認証情報を窃取します。 ⚠️ 実際のリスク ✅ 現実的な対策 Credential Stealer の脅威 人気パッケージの偽装版（例： colourama → colorama ）が、 インストール時に ~/.aws/credentials を外部送信する事例が 多発しています。開発者の環境から本番環境の認証情報まで狙 われています。 依存関係の連鎖汚染 一つのパッケージが数百の依存関係を持つ現代では、深い階層 の依存関係に悪意のあるコードが潜んでいても発見は困難で す。正規パッケージのアップデートに紛れて侵入することもあ ります。 CI/CD パイプラインの標的化 GitHub Actions や Jenkins の設定ミスを狙い、ビルド時に悪 意のあるコードを注入。環境変数に設定されたシークレットを 窃取し、本番環境への侵入経路を確保します。 ①脅威概要 ②認証情報 最小限の権限での開発 開発環境では本番の認証情報を扱わない、必要最小限の権限の み付与、短期間の一時認証情報を使用することで、万が一の被 害を限定します。 依存関係の監査 npm audit 、 pip-audit 、 Dependabot などの自動ツールを 活用。新規パッケージ追加時は、ダウンロード数、メンテナ情 報、最終更新日を必ず確認します。 環境の分離と監視 開発・ステージング・本番環境を完全分離、各環境で異なる認 証情報を使用、CloudTrail で異常な API 呼び出しを監視する ことで、侵害の早期発見を可能にします。 ③フィッシング ④設定不備 ⑤サプライチェーン ⑥リソース侵害 31

6 リソース侵害と対策 内部者による情報漏洩の多くは退職前後に発生し、外部攻撃より被害額が大きく、発見に長期間かかります。最 小権限の原則と継続的な監視により、悪意の有無に関わらず被害を最小化できます。 ⚠️ 脅威の種類 ✅ 実践的な対策 悪意ある内部者 最小権限の徹底 意図的なデータ窃取、競合への情報提供、報復的なシ IAM Identity Center で一元管理、JIT（Just-Inステム破壊 Time）アクセス、定期的な権限棚卸し 非悪意的な内部者 行動監視と分析 設定ミス、フィッシング被害、過失による情報流出 GuardDuty の異常検知、CloudTrail ログ分析、 Access Analyzer で過剰権限を特定 権限の悪用 過剰な権限付与、長期間の権限放置、退職者アカウン 迅速な対応体制 トの残存 自動化された権限剥奪、インシデント対応手順の整 備、定期的な訓練実施 🗒️ ノート 💡 内部者脅威は完全に防げませんが、「信頼するが検証する」アプローチで被害を最小化できます。 ①脅威概要 ②認証情報 ③フィッシング ④設定不備 ⑤サプライチェーン ⑥リソース侵害 32

1. 背景理解 2. 大まかな対策の指針 3. 具体的な脅威と個別対策 4. 具体的な対策と活用 5. まとめと継続的な学習 Chapter 4 具体的な対策と活用 AWS セキュリティサービスで守りを固める 本セクションのトピック 1 AWS セキュリティサービス全体像 4 アクセス制御の実装 2 検知・監視サービスの活用 5 データ保護サービス 3 設定管理と自動化 6 実装ベストプラクティス 33

1 AWS セキュリティサービス全体像 AWS が提供する 20 以上のセキュリティサービスのうち、まず導入すべき必須サービスはわずか 4 つです。こ れらを適切に組み合わせることで、セキュリティインシデントの 90%以上を防ぐことができます。 📖 検知・監視 ✅ 設定管理 🚨 アクセス制御 ⚡ データ保護 ● GuardDuty ● Security Hub ● CloudTrail ● Config ● Systems Manager ● CloudFormation ● IAM ● Organizations ● SSO ● KMS ● Macie ● ACM 💡 脅威検知 ✅ 自動化 ①サービス全体像 ②検知・監視 ❌ 権限管理 ③設定管理 ④アクセス制御 💡 暗号化 ⑤データ保護 ⑥ベストプラクティス 34

2 検知・監視サービスの活用 予算を抑えて始められる基本的なセキュリティ対策が、甚大な被害を防ぎます。完璧を求めて何もしないより、 今すぐできる対策から始めることが、組織を守る最善の方法です。 💡 Phase 1: 基盤構築（初期段階） ✅ Phase 2: 検知強化（次段階） 必須サービス（最小限の予算） 推奨サービス（追加予算が必要） ● CloudTrail 全リージョン ● IAM MFA 必須化 ● Config 基本ルール ● S3 暗号化 ● GuardDuty 脅威検知 ● Security Hub 統合 ● Config 拡張ルール ● SSM パッチ管理 最優先理由 投資効果 ● 侵害調査必須 ● 最小限の予算 ● 即効性 ● 24 時間自動監視 ● 効率的な検出 ● 自動コンプライアンス 👀 重要 💡 小規模環境なら限られた予算でも基本的なセキュリティ対策が実装可能です。 ①サービス全体像 ②検知・監視 ③設定管理 ④アクセス制御 ⑤データ保護 ⑥ベストプラクティス 35

3 設定管理と自動化 🚨 Phase 3: 自動対応（成熟段階） セキュリティ侵害の多くは人的ミスが原因です。自動 化により、この人的ミスを排除し、継続的で一貫した 防御を実現できます。 自動化サービス（本格的な予算確保） ● Lambda 自動修復 ● WAF 攻撃防御 ● Macie データ分類 ● Secrets Manager 💬 Phase 4: 最適化（継続的） エンタープライズレベルの組織では、統制とガバナン スの欠如が最大のリスクとなります。Phase 4 の投資 は、単なるセキュリティではなく、ビジネスの継続性 を守る戦略的投資です。 高度な対策 ● Organizations 統制 ● Control Tower ガバナンス ● Detective 調査 ● カスタム開発 実装効果 成熟度向上 ● 自動対応 ● 即座修正 ● 自動保護 ● 企業統制 ● 予防対策 ● 脅威ハンティング 🗒️ ノート 📊 多くの組織で、Phase 2まで実装することでセキュリティインシデントを大幅に削減できています。 ①サービス全体像 ②検知・監視 ③設定管理 ④アクセス制御 ⑤データ保護 ⑥ベストプラクティス 36

4 アクセス制御の実装 IAM は AWS セキュリティの基盤です。最小権限の原則を徹底し、ルートアカウントの保護、MFA の必須化、 役割ベースのアクセス制御を実装することで、攻撃者が最も狙うポイントを確実に防御できます。 📖 ルートアカウントの完全保護 ✅ IAMユーザーの適切な管理 なぜルート保護が最優先なのか 「誰が」に「何を」できるかを厳密に管理 ルートアカウントは全てのリソースを削除できる「神 IAM ポリシーは JSON で記述され、非常に柔軟に権 の権限」を持ちます。MFA を設定し、アクセスキーを 限を設定できます。個人に直接権限を付与するのでは 削除、日常業務では絶対に使用しないことで、組織の なく、Developer、Admin、ReadOnly などの役割 存続に関わるリスクを排除できます。 （ロール）を定義し、必要に応じて一時的に権限を昇 具体的な保護手順 格させる仕組みにより、常時高権限による事故を防止 1 ハードウェア MFA または仮想 MFA デバイスを設定 します。 1 [優先] ハードウェア MFA は YubiKey などの物理デバイス パスワードポリシーの重要性 を使用 ではユーザーの設定するパスワードの複雑さや有 2 [次善策] 仮想 MFA は 1Password などの信頼できるアプ IAM 効期限をポリシーで強制できます。十分な長さと複雑 リを使用 さを持つパスワードを要求し、過去のパスワードの再 2 既存のアクセスキーを即座に削除 利用を防ぐことで、総当たり攻撃やパスワードリスト 3 CloudTrail でルート使用を監視・アラート設定 攻撃を効果的に防げます。 4 MFA デバイスを安全な場所に保管 ①サービス全体像 ②検知・監視 ③設定管理 ④アクセス制御 ⑤データ保護 ⑥ベストプラクティス 37

5 データ保護サービスの活用 暗号化されていないデータは「裸の現金」と同じです。AWS のデータ保護サービスを活用することで、保存時 も転送時も完全に保護され、万が一の漏洩時でもデータは解読不可能となります。 📖 S3の暗号化と保護 ✅ データの暗号化と管理 デフォルト暗号化の設定 S3 バケットレベルで SSE-S3（AES-256）暗号化を強制するこ とで、アップロードされる全てのオブジェクトが自動的に暗号化 されます。設定忘れによる平文保存を完全に防止できます。 バケットポリシーとアクセス制御 { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::bucket/*", "Condition": { "Bool": { "aws:SecureTransport": "false" } } } ] KMS による鍵管理 KMS を利用することで、CMK（Customer Master Key）を使 った高度な鍵管理が可能です。アクセス制御、監査証跡、自動ロ ーテーションにより、鍵の安全性と運用効率を大幅に向上できま す。 Secrets Manager で認証情報管理 Secrets Manager を利用することで、データベース認証情報や API キーを安全に保存し、アプリケーションから安全に取得でき ます。ハードコードを排除し、認証情報の自動ローテーションも 可能です。 DynamoDB などのサービスにおけるデータ暗号化 AWS のマネージドサービスは多くが保存時暗号化をサポートして います。DynamoDB、RDS、EFS などで暗号化を有効にし、デ ータ保護を徹底しましょう。 } ①サービス全体像 ②検知・監視 ③設定管理 ④アクセス制御 ⑤データ保護 ⑥ベストプラクティス 38

5 データ保護サービスの活用 - 発展 Macie による機密データの自動発見とCloudHSM による規制準拠、Certificate Manager による証明書管 理により、データ保護の完全自動化を実現できます。人的ミスによるデータ漏洩リスクを根本から排除します。 📖 Amazon Macie ⚡ CloudHSM 🚨 Certificate Manager 機密データの自動発見 ハードウェアセキュリティモジュ SSL/TLS 証明書の自動管理 S3 バケット内の PII（個人識別情 ール 証明書の発行、更新、配布を完全 報）、クレジットカード番号、認証 FIPS 140-2 レベル 3 認証取得の 自動化。証明書の期限切れによる 情報を機械学習で自動検出。知ら 専用ハードウェアで暗号鍵を保 サービス停止を防止します。 ないうちに保存された機密データ 護。金融機関や医療機関の厳格な 統合サービス も見逃しません。 規制要件にも対応可能です。 ELB、CloudFront、API リスクスコアリング 完全な鍵の所有権 Gateway と統合。ワンクリック 発見したデータの重要度と露出リ AWS でも鍵にアクセスできな で HTTPS 化を実現し、転送中の スクを自動評価。優先対応すべき い、完全にお客様管理の暗号化を データを確実に保護します。 バケットが一目瞭然になります。 実現。最高レベルのデータ主権を ❌ 自動更新 確保します。 💡 ML 検出 ✅ 規制準拠 ①サービス全体像 ②検知・監視 ③設定管理 ④アクセス制御 ⑤データ保護 ⑥ベストプラクティス 39

6 実装ベストプラクティス - 基本設定 ルートアカウントのパスワードが「Password123!」、MFA 未設定、アクセスキーが有効のままという信じられ ないセキュリティ状態が、大企業でも珍しくありません。今すぐ実施すべき基本設定により、攻撃者から最も狙 われるポイントを確実に防御できます。 📖 ルートアカウントの完全保護 ✅ IAMユーザーの適切な管理 なぜルート保護が最優先なのか パスワードポリシーの重要性 ルートアカウントは全てのリソースを削除できる「神 単純なパスワードは短時間で破られます。十分な長さ の権限」を持ちます。MFA を設定し、アクセスキーを と複雑さを持つパスワードを要求し、過去のパスワー 削除、日常業務では絶対に使用しないことで、組織の ドの再利用を防ぐことで、総当たり攻撃やパスワード 存続に関わるリスクを排除できます。 リスト攻撃を効果的に防げます。 具体的な保護手順 役割ベースのアクセス制御 1 ハードウェア MFA または仮想 MFA デバイスを設定 個人に直接権限を付与するのではなく、Developer、 Admin、ReadOnly などの役割（ロール）を定義し、 2 既存のアクセスキーを即座に削除 必要に応じて一時的に権限を昇格させる仕組みによ 3 強固なパスワードを設定後、金庫で管理 り、常時高権限による事故を防止します。 4 CloudTrail でルート使用を監視・アラート設定 ①サービス全体像 ②検知・監視 ③設定管理 ④アクセス制御 ⑤データ保護 ⑥ベストプラクティス 40

6 実装ベストプラクティス - 高度な設計 最小権限の原則と自動修正、アカウント分離の 3 つの柱により、人的ミスを防ぎ、被害を最小限に抑える堅牢な セキュリティアーキテクチャを構築できます。これらは追加予算を最小限に抑えて実装可能な、AWS WellArchitected の中核となる設計パターンです。 📖 最小権限の原則 ⚡ Config自動修正 🚨 アカウント分離 権限の段階的付与 ● 必要最小限から開始 ● 要求に応じて追加 ● 定期的な棚卸し 自動修正ルール例 IAM Policy Simulator の活用 ● 権限の事前検証 ● 影響範囲の確認 ● 段階的な展開 環境別分離 ● S3 公開設定の即座修正 ● SG の過度開放を自動閉鎖 ● タグ付けルールの強制 ● 本番：最高レベル保護 ● ステージング：本番同等 ● 開発：柔軟性重視 Systems Manager 連携 Organizations 活用 RemediationConfiguration: TargetType: SSM_DOCUMENT TargetId: AWS-PublishSNSNotification Parameters: AutomationAssumeRole: arn:aws:iam::123456789012:role/RemediationRole 💡 基本原則 ● SCP によるガードレール ● 統合請求管理 ● CloudTrail 集約 ❌ 分離戦略 ✅ 自動化 ①サービス全体像 ②検知・監視 ③設定管理 ④アクセス制御 ⑤データ保護 ⑥ベストプラクティス 41

1. 背景理解 2. 大まかな対策の指針 3. 具体的な脅威と個別対策 4. 具体的な対策と活用 5. まとめと継続的な学習 Chapter 5 まとめと継続的な学習 セキュリティスキルを継続的に向上させるために 本セクションのトピック 1 重要ポイントの振り返りと実践ロードマップ 2 継続的な学習とコミュニティ活動 42

1 重要ポイントの振り返りと実践ロードマップ 今日学んだ 4 つの基本原則を実践すれば、セキュリティインシデントの大部分を防げます。完璧を求めず、今週 中に第一歩を踏み出すことが、組織を守る最も確実な方法です。 📖 学習内容の要点 ⚡ 今すぐ実行すべきアクション Chapter 1-2: 基礎理解 今週中に実施（緊急） ● クラウドの両面性：利便性と脅威は表裏一体 ● Well-Architected 原則：最小権限と多層防御 ● 責任共有モデル：AWS と利用者の境界理解 Chapter 3-4: 実践的対策 ● 5 大脅威（認証情報漏洩、フィッシング、設定不備、サプライチ ェーン、リソース侵害）への対応 ● GuardDuty、Config、Macie など必須サービスの活用方法 ● データ保護：KMS 暗号化、Secrets Manager、証明書管理 ● 最小権限の原則、Config 自動修正、アカウント分離の実装 ● Phase 別実装：基盤構築 → 検知強化 → 自動対応 → 最適化 1 ルートアカウントの MFA 設定とキー削除 2 CloudTrail 全リージョン有効化 3 S3 バケットの公開設定確認 4 IAM ユーザーの権限監査 今月中に実施（重要） ● GuardDuty 有効化と通知設定 ● Config 基本ルールの設定 ● パスワードポリシーの強化 ● 最小権限の原則に基づく権限見直し ①振り返りと実践 ②継続学習 43

2 継続的な学習とコミュニティ活動 セキュリティの脅威は日々進化しています。継続的な学習と情報収集により、新たな脅威に対応し、組織のセキ ュリティ文化を醸成することが、真のセキュリティエキスパートへの道です。 📖 情報収集源 ✅ コミュニティ 🚨 成功の鍵 AWS 公式 日本 マインドセット ● Security Blog ● Security Bulletins ● What's New 脅威情報 ● MITRE ATT&CK ● CISA Alerts 学習リソース ● Skill Builder ● Workshop Studio 💡 継続学習 ● JAWS-UG ● Security JAWS ● AWS Summit ● 継続性 > 完璧性 ● 実践 > 理論 ● 協力 > 孤立 オンライン キャリア開発 貢献方法 最終メッセージ セキュリティは全員の責任 ❌ 文化醸成 ● re:Post ● Stack Overflow ● LinkedIn ● ブログ執筆 ● 勉強会発表 ✅ ネットワーク ● AWS 認定資格 ● 実践経験蓄積 ● 知識共有 ①振り返りと実践 ②継続学習 44

ご清聴ありがとうございました！ AWS セキュリティの全体像を理解しよう 初学者が知るべき脅威と対策 2025/09/11 JAWS-UG 初心者支部#68 残暑のサメとあざらし Security-JAWS コラボ LT 回！ Azara / Norihide Saito https://x.com/a_zara_n 45

• https://x.com/a_zara_n