Amazon Web Services ブログ
攻撃者視点で考える AWS セキュリティ ― 富士通 × AWS 共催セミナーレポート
こんにちは。AWS ソリューションアーキテクトの松井です。
2026 年 3 月 18 日、富士通株式会社様(以下、同社)と AWS の戦略協業組織「Business Creation Lab(BC Lab)」の取り組みとして、「セキュリティ対策セミナー ~ホワイトハッカー登壇!攻撃者視点×クラウド設計で実現する実践的サイバー防衛~」を開催しました。本セミナーでは、AWS のセキュリティサービスの紹介に加え、同社 Uvance Wayfinders のホワイトハッカーチーム(Red Team)による日本企業のセキュリティ実態の共有、そしてライブハッキングデモンストレーションを実施しました。
本記事では、セミナーの内容をご紹介します。
Business Creation Lab (BC Lab) について
本セミナーは、同社と AWS の戦略協業組織「Business Creation Lab (BC Lab)」の活動の一環として開催されました。BC Lab は、同社の業界知見・テクノロジーソリューションと AWS の生成 AI・クラウドサービスを融合し、お客様の経営課題解決を支援する拠点です。詳細については、同社のプレスリリースをご覧ください。
当日はお客様約 30 名にご参加いただき、同社社員含め最大 100 名が視聴しました。
サイバー脅威の加速と AI が変えた攻撃の現実
最初のセッションでは、AWS ソリューションアーキテクトの松井より、サイバー攻撃の最新動向を共有しました。
ランサムウェア、サプライチェーン攻撃、不正送金 ― サイバー脅威はあらゆる面で拡大を続けています。IPA「情報セキュリティ 10 大脅威 2026」では、ランサムウェアが 11 年連続で 1 位となる一方、「AI の利用をめぐるサイバーリスク」が初めて 3 位に選出されました。AI の登場により、脅威の質そのものが変わりつつあると考えられます。
実際、RSAC 2025 のキーノートセッション「The Five Most Dangerous New Attack Techniques」において、SANS Institute の Rob Lee 氏は MIT の研究を引用し、AI エージェントによる攻撃シーケンスは人間オペレーターの 47 倍の速度で実行され、権限昇格の成功率は 93% に到達していると指摘しています。
こうした脅威の加速を踏まえ、本セミナーでは「攻撃者の視点」と「クラウド設計」の両面からセキュリティを考えるアプローチを取りました。まずは、約 200 社へのハッキング実績を持つホワイトハッカーの知見から紹介します。
ハッカー視点で見る日本企業のセキュリティ
本セッションでは、同社 Uvance Wayfinders の佐藤丈師氏(Red Team テストを専門とし、200社以上のハッキング実績を持つホワイトハッカー)が登壇しました。佐藤氏の知見は、Uvance Wayfinders のインサイト記事「ホワイトハッカーが解き明かすセキュリティ再設計」でも詳しく紹介されていますので、あわせてご覧ください。
約 200 社への Red Team テストから見えた傾向

Red Teamテストの流れ
佐藤氏は、これまでに約 200 社に対して実施した Red Team テストの結果から、日本企業のセキュリティの実態を共有しました。
佐藤氏によると、傾向として 「境界防御は強い一方、侵入後は弱い」 とのことです。
境界防御の面では、脆弱性も設定不備もほとんどなく、EDR / NDR / CASB などで多層防御を構築し、SOC による 24/365 の監視体制を整え、定期診断・監査・CSIRT 体制も整備されている企業が多いとのことです。
しかし、一度境界を突破されると状況は変わります。侵入を前提とした訓練・体制が不十分で、アクセス制限が甘く横展開が容易、製品導入で満足しベンダに丸投げしている ― という傾向が見られるとのことでした。
Red Team テストの数字
佐藤氏が共有した Red Team テストの結果は、以下の通りです:
- 物理侵入の成功率:ほぼ 100%
- フィッシングメールのファイル開封率:約 60%
- 重大インシデントとなる大穴の検出率:ほぼ 100%
- 侵入後ドメイン管理者取得まで:約 7 割の組織で 1 日
- Red Team テストを検知して対応できた組織:約 10%
まずはリスクの可視化、順番が重要
佐藤氏は、セキュリティ対策の優先順位として以下の 3 ステップを提示しました:
- リスクの可視化(Red Team テスト等) ― 攻撃者の視点でリスクを可視化し、重大インシデントの原因となる大穴をなくす
- 検知・防御力の整備 ― 大穴がなければ攻撃者は攻めあぐねる。その間に検知・防御する
- インシデント対応力の強化 ― 検知・防御の仕組みが整ったら、アラートへの適切な対応力を訓練する
Red Team テストで見つかる AWS 関連のリスク
佐藤氏は続けて、Red Team テストで実際に検出される AWS 関連のリスクについても共有しました。
佐藤氏が強調していたのは、「主な検出リスクは『使い方』に起因するものであり、AWS そのもののリスクではない」という点です。内部環境が侵害されると、クラウド環境にも波及するというのが典型的なパターンとのことです。
よくあるリスクとして、以下の 2 つが挙げられました:
リスク①:認証情報管理の不備
- クラウドのログイン鍵が社内共有フォルダに置かれている
- パスワードや認証情報が管理表にまとめて保存されている
- AWS で「何でもできる権限」が広く付与されている
リスク②:ID 連携・権限設計の不備
- 内部ネットワークが侵害されるとクラウドにも侵入される
- 開発環境と本番環境が同じ認証でつながっている
- SSO ユーザが管理者レベルの権限を持っている
AWS のセキュリティサービスと攻撃者視点の対応
ここからは、Red Team が指摘したリスクに対して、AWS がどのようなセキュリティの仕組みを提供しているかを紹介します。AWS 松井のセッション内容をもとに、攻撃者の視点との対応関係を交えて解説します。
AWS セキュリティの基盤:責任共有モデル
AWS では「Security is our top priority(セキュリティは最優先事項)」を掲げています。
AWS のセキュリティは「責任共有モデル」を基盤としています。AWS がクラウド「の」セキュリティ(物理インフラ、ネットワーク、ハイパーバイザーなど)を担い、お客様がクラウド「内」のセキュリティ(データ、アプリケーション、ID とアクセス管理など)を担います。
佐藤氏が「AWS そのもののリスクではなく使い方の問題」と指摘したのは、まさにこの「クラウド内のセキュリティ」に該当する領域です。NIST Cybersecurity Framework(CSF)に沿って整理すると、AWS は「識別(Identify)→ 防御(Protect)→ 検出(Detect)→ 対応(Respond)→ 復旧(Recover)」の各フェーズに対応するセキュリティサービス群を提供しています。本セッションでは、Red Team の指摘と最も密接に関わる「防御(Protect)」― とりわけ IAM を中心とした認証・認可の領域に焦点を当てて紹介しました。
防御:IAM ベストプラクティスの変化(2019 年→ 2026 年)
Red Team が指摘した「認証情報管理の不備」「ID 連携・権限設計の不備」に直接対応するのが、ID とアクセス管理(AWS Identity and Access Management(IAM))です。本セッションでは、IAM のベストプラクティスがこの 7 年間でどのように進化したかを紹介しました。
2019 年時点のベストプラクティスは、以下のような内容でした:
- AWS アカウントのルートユーザーアクセスキーをロックする
- 個々の IAM ユーザーを作成
- ユーザーの強力なパスワードポリシーを設定
- 特権ユーザーに対して MFA を有効化する
- AWS 管理ポリシーを使用したアクセス許可の使用開始
2026 年現在のベストプラクティスでは、以下のような項目が求められるようになっています:
- 人間のユーザーが AWS にアクセスする場合に ID プロバイダーとのフェデレーションを使用して一時的な認証情報でアクセスすることを求める
- ワークロードが AWS にアクセスする場合に IAM ロールで一時的な資格情報を使用することを求める
- 多要素認証(MFA)を必須とする
- 長期的な認証情報を必要とするユースケースのためにアクセスキーを必要な時に更新する
- IAM Access Analyzer を使用して、アクセスアクティビティに基づいて最小特権ポリシーを生成する
- 未使用のユーザー、ロール、アクセス許可、ポリシー、および認証情報を定期的に確認して削除する
- アクセス許可の境界を使用して、アカウント内のアクセス許可の管理を委任する
2019 年には「個々の IAM ユーザーを作成」が推奨されていたのに対し、2026 年では「ID プロバイダーとのフェデレーション」や「一時的な資格情報の使用」が求められるようになっています。長期的な認証情報(アクセスキー)への依存を減らす方向に進んでいることがわかります。
Red Team の指摘と AWS ベストプラクティスの対応関係
佐藤氏が指摘した改善ポイントは、AWS の IAM ベストプラクティスで対応できる部分が多くあります。以下の表は、佐藤氏の推奨アクションと、対応する AWS のベストプラクティスを整理したものです。
| 攻撃者の動き | Red Team の推奨アクション | 対応する AWS のベストプラクティス |
|---|---|---|
| ① Credential を探す | 長期 Credential の排除、SSO 移行、IAM ロール使用 | ID プロバイダーとのフェデレーション、一時的な資格情報の使用 |
| ② IAM 権限を見る | 認証情報の保存をやめる、Secrets Manager 移行 | アクセスキーを必要な時に更新、長期認証情報の最小化 |
| ③ 昇格する | Least Privilege 適用、IAM Access Analyzer 活用 | IAM Access Analyzer で最小特権ポリシーを生成、未使用の権限を定期削除 |
攻撃者が狙うポイントを理解することで、AWS のベストプラクティスがどのような背景で推奨されているのか、より具体的にイメージしやすくなるのではないかと思います。
ライブハッキングデモンストレーション
同社 Uvance Wayfinders の番場陸氏によるライブハッキングデモンストレーションも実施されました。
デモの流れ
このデモでは、日系の中小企業(人材派遣会社を想定)を対象に、端末の感染から AWS 環境への横展開・特権取得までを再現しました。攻撃シナリオの概要は以下の通りです:
- 境界突破 ― フィッシングメールによる従業員端末のマルウェア感染
- 横断的侵害 ― 内部ネットワーク上のファイルサーバを探索し、AWS 環境への足がかりを発見
- 権限昇格 ― AWS 環境内部のリソースを悪用した権限昇格
- 目的の達成 ― AWS 上に保存されている顧客情報の窃取
会場では、攻撃者の画面をリアルタイムで投影しながら、各ステップで「なぜこの攻撃が成功するのか」「どこで検知・防御できたはずか」を解説しました。参加者からは「自社でも同じことが起こりうると実感した」という声が多く聞かれました。
参加者の声
セミナー後のアンケートでは、参加者の満足度は 5 段階評価で平均 4.32 でした。
参加者のセキュリティ対策の状況としては、72% が「一通りは実施しているが、十分か不安がある」と回答しました。
今後の関心事項としては、「AWS 環境のセキュリティ設計・運用を確認したい」「現状の課題や弱点を整理したい(簡易診断・アセスメント)」「優先順位や進め方を整理したい(ロードマップ策定)」等のフィードバックをいただきました。
まとめ
本セミナーでは、同社 Uvance Wayfinders のホワイトハッカーによる実践的な知見と、AWS のセキュリティサービスの紹介を通じて、「攻撃者の視点」と「防御側の設計」の両面からセキュリティを考える機会となりました。
「対策はしているが十分か不安」という企業にとって、攻撃者の視点でリスクを可視化すること、そして AWS のベストプラクティスに沿ったクラウド設計を進めることは、有効なアプローチの一つになり得ると考えています。
BC Lab では、セキュリティに限らず、生成 AI やデータ活用、レガシー刷新など幅広い領域でお客様の経営課題解決を支援しています。今回のセキュリティセミナーのように、同社の実践知と AWS のテクノロジーを掛け合わせた取り組みを今後も展開していきます。


