AWSシステムを想定したセキュリティ対策とデータ保護の考え方

AWSシステムを想定した セキュリティ対策とデータ保護の考え方 バーンワークス株式会社 セキュリティ勉強会資料

はじめに この資料の目的と前提 2

これからのセキュリティ対策の基本的な考え方を紹介 現在のセキュリティ対策では、「入口で防ぐ」ことに加え、侵入されてしまった場合においても「被害を 小さくする」ための備えが重要です。 例えばWAFは、既知の攻撃パターンなどを検知・遮断する有効な対策ですが、未知の攻撃や、正規の 操作に見える攻撃をすべて防げるわけではありません。そのため、権限の制限、ネットワークの分離、 データ保護、異常の検知など、複数の対策を組み合わせることが必要となります。 この勉強会では、AWS上で運用するシステムを題材に、それぞれの対策が何を守り、どのような限界 があるのかを学びます。また、外部サービスと連携する場合の注意点も取り上げます。 自分たちのシステムに置き換えながら、「何を守る必要があるか」「どこを見直すとよいか」を一緒に 考えていきましょう。 3

前提（1）： 外部サービスと連携する場合のシステム構成 対策を具体的に考えやすくするため、外部サービスとの連携においては次の構成を例にします。 • 自社で開発したシステムがAWS上で動いており、入口をAWS WAF（Web Application Firewall ）で防御している。 • 自社システムは他の外部システムとインターネット経由でデータをやり取りしている。通信は HTTPSで暗号化し、外部システム側では送信元IPアドレスの制限とAPIの認証情報で接続元を限 定している。 この構成はあくまで一例です。各対策の目的を理解し、自分たちのシステムの構成や責任範囲に合わ せて考えていきましょう。 4

前提（2）： この資料での呼び方と責任範囲 この例では、外部事業者が提供するサービス（SaaSを想定）を「外部システム」、AWS上の自社開発 システムを「自社システム」と呼びます。 一般的に外部システムの基盤やサービス自体の防御は、主にサービス提供事業者が担います。 一方、自社が管理する利用者アカウント、権限、共有・連携設定といった認証情報、および自社システ ムの防御は自社の責任範囲です。 ただし、実際の運用における具体的な責任範囲、役割分担は、サービスの仕様と契約内容等で決まり ますので上記の限りではありません。 5

主な出典（1）AWSとNISTの基本文書 • AWS Well-Architected フレームワーク セキュリティの柱（AWS、2024年11月版）： AWSが公開する安全なワークロード設計の公式ベストプラクティス集です。「すべてのレイヤーでセキュリティ を適用する」「セキュリティイベントに備える」などを設計原則に掲げており、この資料全体の土台にしています 。 • NIST SP 800-207 Zero Trust Architecture（米国国立標準技術研究所、2020年8月）： ゼロトラストの定義文書です。ネットワーク上の位置だけを理由に信頼を与えない、という考え方の出典です。 非公式の日本語訳も同ページで案内されています。（NIST SP 800 シリーズに関する解説は後述） 6

• https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/welcome.html
• https://csrc.nist.gov/pubs/sp/800/207/final

主な出典（2）OWASPとは • OWASP（Open Worldwide Application Security Project、旧称 Open Web Application Security Project）： OWASPはソフトウェアのセキュリティ向上を目的とする国際的な非営利団体です。2001年に活動を始め、 2004年に米国の非営利団体として法人化されました。世界中の技術者が参加するオープンなコミュニティで 、成果物はすべて無料で公開されています。 特定企業の製品に依存しない中立的な立場で作られているため、「OWASP Top 10」や「Cheat Sheet Series」は、ウェブアプリケーションセキュリティの事実上の業界標準として広く参照されています。 ただし、法令や公的な規格ではないため、本資料ではIPA、経済産業省、個人情報保護委員会などの国内の公 的資料とあわせて根拠にしています。 7

• https://owasp.org/about/

主な出典（3）NIST SP 800シリーズとは • NIST SP 800シリーズ： 米国商務省に属する国立標準技術研究所（NIST）が発行する、コンピュータセキュリティの指針文書群です。 米国の政府機関が対策を実施する際に使うことを前提に作られていますが、セキュリティマネジメント、リスク 管理、技術的対策、インシデント対応まで幅広く網羅しており、民間企業でも世界的な共通の参照先になってい ます。 代表的なものに、管理策の一覧であるSP 800-53、パスワードや認証の扱いを定めるSP 800-63、ゼロト ラストのSP 800-207があります。本資料では、このうちSP 800-207（ゼロトラスト）、SP 800-190（コ ンテナ）、SP 800-61 Rev. 3（インシデント対応）を根拠にしています。主要な文書はIPAが日本語訳を公開 しています。 8

• https://www.ipa.go.jp/security/reports/oversea/nist/nist_publications.html
• https://www.ipa.go.jp/security/reports/oversea/nist/index.html

本題に入る前に： 経営層の皆さまへ 本勉強会および本資料は、主にシステム開発や運用に携わるエンジニアの皆さまを対象としています が、本題に入る前に、経営層の皆さまにも共有したい点をお伝えします。 • セキュリティ対策は経営課題である • 認証情報を守るには、技術対策と企業ガバナンスの両方が必要である 9

セキュリティ対策は経営課題である サイバー攻撃による被害は、システムだけの問題にとどまりません。 業務の停止、情報の漏えい、取引先への影響は、売上や企業の信用を損なうおそれがあります。 どの業務と情報を優先して守るか、どこまでのリスクを受け入れるか、対策にどれだけの予算と人員 を充てるか。これらは、技術担当者だけでは決められない経営判断です。 経営層には、判断に必要な情報を担当者から得て、対策の優先順位と責任者を明確にし、継続して取 り組める体制を整える役割があります。 10

認証情報を守るには、技術対策と企業ガバナンスの両方が必要である 本勉強会の主要テーマであるAWSの権限管理や多要素認証などの技術対策は重要です。 しかし、会社として「どのアカウントを誰が何のために使っているか」を把握していなければ、対策の対象から漏 れるものが生まれます。盗まれた認証情報が悪用されると、正規の利用との区別が難しくなるため、企業にとっ て大きな脅威となります。 管理の対象は、パソコンのログインIDだけではありません。オンラインサービスのアカウント、管理者アカウント、 システム間連携のAPIキーやトークンなども含まれます。また、委託先や取引先が自社のシステム・データにアク セスするためのアカウントも対象です。 退職者のアカウント、担当者が不明なAPIキー、無断で利用しているサービスなどが残っていれば、そこが不正ア クセスの入口になるおそれがあります。 認証情報の防御を、個々の担当者の注意や設定だけに任せてはいけません。把握・ルール策定・監査・是正を継 続する仕組みが、技術対策を組織全体に行き渡らせます。 11

把握・ルール策定・監査・是正を継続する • 何を使っているか把握する： 業務で使うアカウントや認証情報について、利用先、用途、管理責任者、権限、利用終了の条件を整理します。なお、台帳には管理に必要な情 報を記録し、パスワードやAPIキーの値そのものは記載しません。 • 取り扱いルールを決める： 発行・承認、保管、共有の制限、多要素認証、権限の変更、不要になった際の無効化までを定めます。異動・退職・契約終了時の対応と、例外を 認める条件も明確にします。 • 実際の運用を定期的に監査する： 台帳と実際の利用状況を照合し、未登録のアカウント、過剰な権限、不要な認証情報、ルール違反がないかを確認します。委託先にも、契約や 責任分担に応じて確認を求めます。 • 問題を是正し、再発を防ぐ： 問題ごとに対応責任者と期限を決め、無効化や権限の見直しを行います。対応の完了を確認し、必要に応じてルールや仕組みも改善します。 経営層や管理部門は責任と体制を定め、エンジニアは設定・記録・自動化によって運用を支えます。 認証情報の管理は、経営層・管理部門・エンジニアが連携して継続する取り組みです。 12

本題に入ります

全体像 セキュリティ対策におけるレイヤー 14

入口を破られてもレイヤー構造により被害を最小限に食い止める 攻撃 レイヤー1 入口（WAF） 既知の攻撃と機械的な大量攻撃をふるい落とす レイヤー2 アプリケーション 脆弱性を作らない、ライブラリの脆弱性を早く直す レイヤー3 実行環境 乗っ取られても、サーバ上でできることを減らす レイヤー8 検知と対応 レイヤー4 権限管理 奪われた権限でAWS全体へ広がるのを防ぐ 全ての層を監視し 早く気づいて止める レイヤー5 ネットワーク 横への移動と、外へのデータ持ち出しを防ぐ レイヤー6 データ保護 盗めるデータを減らし、盗んでも使えなくする レイヤー7 外部システムとの連携 自社システムの侵害を外部システムへ広げない 土台：データ保存ポリシー 持たないデータは漏れない。取得しない・持たない・早く消す ※この図は対策を役割ごとに整理したものです。実際の攻撃が、レイヤー1から必ず順番に進むことを示すものではありません。盗まれた認証情報の悪用など、入口のWAFを経由し ない攻撃にも備える必要があります。 15

全体像の読み解き方 各レイヤーには防げる攻撃と限界があります。複数のレイヤーを組み合わせ、互いの不足を補います。 土台でデータを減らし、各レイヤーで少しずつ被害を削り、全体を検知で見張るという組み合わせで 、仮に入口を突破されてもそれだけで大きな被害にならない状態を作ります。 攻撃の入口や進み方は一つではありません。Webアプリへの攻撃だけでなく、盗まれた認証情報の 悪用や、開発基盤・連携先を通じた侵害もあります。各レイヤーは互いに補い合って被害を小さくする 役割を持ち、検知レイヤーはすべてのレイヤーを横断して見張ります。 以降では、まず共通の考え方と土台のデータ保存ポリシーを説明し、その後に図の上から順にレイヤ ー1〜8を解説します。 16

基本の考え方 近年のベストプラクティスを5つの原則で整理する 17

5つの原則 本資料では、セキュリティの基本的な考え方を次の5つの原則で整理します。以降解説する個々の対策は、すべてこの いずれかを実現するための手段となります。 原則 意味 わかりやすく例示すると 多層防御 1つの対策に頼らず、複数のレイヤーで守る。どれか1つが破られても次 門、玄関の鍵、金庫などを別々に用意する のレイヤーで止める 侵害前提（Assume Breach） 「いつか入られる」前提で、入られた後の被害を小さくする設計にする 泥棒が入っても金庫は開かない、すぐ通報される 最小権限 人もプログラムも、仕事に必要な最小限の権限だけを持つ 庭師には「庭の整備に必要なエリア」の鍵だけを渡す データ最小化 不要なデータは最初から持たない。持たないデータは漏れない 年齢確認には、必要に応じて生年月日そのものでは なく「20歳以上である」という確認結果だけを残す （例えばお酒を売るとき、身分証で年齢を確かめる だけで、生年月日のコピーは取らないように） ゼロトラスト 「社内ネットワークだから安全」とは考えず、通信ごとに相手を確認する 社員証があっても、部屋ごとに入室を確認する 18

優先的に検討したいデータ最小化 この5つの原則の中でも、データ最小化は、漏えいした場合の被害を減らすために優先的に検討した い対策です。不要なデータを取得・保存しなければ、そのデータが自社システムから漏れるリスクを減 らせます。 ただし、見直しに必要な費用は業務やシステムの構成によって異なります。また、データ最小化は漏え い対策であり、サービス停止や改ざんへの対策は別途必要です。 19

参考となる資料：基本の考え方 • 多層防御：AWS Well-Architected フレームワーク セキュリティの柱： 設計原則「すべてのレイヤーでセキュリティを適用する」。複数のセキュリティ管理を重ねる多層防御を求めています。 • 侵害前提・ゼロトラスト：NIST SP 800-207： ネットワーク境界ではなく個々の資源を守る考え方と、環境内に攻撃者がいる前提で運用する姿勢を示しています。 • 最小権限：IAM のセキュリティベストプラクティス（AWS）： タスクに必要な権限だけを与えることを求めています。 • データ最小化：OWASP Cryptographic Storage Cheat Sheet： 可能な限り機微な情報の保存自体を避けるよう推奨しています。 • データ最小化：個人情報保護法ガイドライン（通則編）： 利用目的をできる限り特定する義務と、利用する必要がなくなった個人データを遅滞なく消去する努力義務を定めています（次のセクション 参照）。 20

• https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/welcome.html
• https://csrc.nist.gov/pubs/sp/800/207/final
• https://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPractices.html
• https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html
• https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/

データ保存ポリシー 土台：そもそも「守るべきもの」自体を減らす 21

データの持ち方：4つのステップ（1） セキュリティ対策の出発点は「守るもの」自体を減らすことです。次の順番で考えます。 • 1. 取得しない： 業務に本当に必要な項目かを、項目ごとに確認します。「念のため」「将来使うかも」で取得した項目は、 漏えい時の被害と法的責任だけを増やします。 • 例：生年月日が必要なのは年齢確認のためなら、「20歳以上かどうか」だけを持てば足ります。 • 例：本人確認書類の画像は、確認が済んだら保持しない運用にできないか検討します。 • 2. 自社で持たない： クレジットカード番号は決済代行会社に預け、自社ではトークン（代わりの識別子）だけを扱います。シス テムの用途によりますが、認証情報についてIDプロバイダーに任せられるならパスワードを自社で持た ずに済む場合もあります。 22

データの持ち方：4つのステップ（2） • 3. 早く消す： 項目ごとに保存期間を決め、期限が来たら自動で削除または匿名化します。法令で保存が必要なも のは、その期間だけ保持します。ログやバックアップ、テスト環境にコピーしたデータも対象です。 • 4. 分類して扱いを変える： 残すデータには重要度のラベルを付け、ラベルごとに保管場所、暗号化、アクセスできる人を決めま す。 23

データ分類の例 分類 例 主な扱い 機密（最重要） パスワード、カード情報、本人確認書類、健康情報 原則持たない。保存が必要な場合は、パスワードには専用の ハッシュ方式を使い、元の値が必要な情報には個別暗号化を 使う。保管場所とアクセス権限も分離する 個人情報 氏名、住所、電話番号、メールアドレス 個別暗号化やマスキングを検討し、アクセスできる人と処理を 限定する 社内情報 予約件数、売上、設定値 通常の暗号化と権限管理で守る 公開情報 施設情報、料金表 改ざん防止を中心に守る 分類を決めることにより、後のレイヤーにおける対策（暗号化の範囲、監視の重点、バックアップの扱い）をどこまで厚く するかを、根拠を持って判断できるようになります。 24

参考となる資料：データ保存ポリシー • 個人情報の保護に関する法律についてのガイドライン（通則編）（個人情報保護委員会、令和8年6月一部改正）： 利用目的をできる限り特定すること（法第17条）、利用する必要がなくなった個人データを遅滞なく消去するよう努めること（法第22条）、安 全管理措置（法第23条）を定めています。 取得する項目や保存期間を見直す際に踏まえるべき規定です。なお、法令は「不要な項目を取得してはならない」とまでは定めていません。 「不要な項目を取得しない」は、利用目的に照らして本資料が推奨する方針です。 • クレジットカード・セキュリティガイドライン（クレジット取引セキュリティ対策協議会）： 割賦販売法のセキュリティ対策義務の実務上の指針です。加盟店にはカード情報の非保持化、またはPCI DSSへの準拠が求められています。 加えて、EC加盟店には脆弱性対策と不正利用対策の実施も求められています。最新版の内容は、日本クレジット協会の掲載ページで確認して ください。 • OWASP Cryptographic Storage Cheat Sheet： 機微な情報は可能な限り保存しないよう推奨しています。 • AWS Well-Architected フレームワーク セキュリティの柱： データ保護の領域で、まずデータを分類し、分類に応じて保護を決めることをベストプラクティスとしています。 先のページで示した、「データ分類の例」は、上記各資料を踏まえ、本資料内でわかりやすく例示したものです。 25

• https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/
• https://www.j-credit.or.jp/security/document/index.html
• https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html
• https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/welcome.html

レイヤー1 入口（WAF・境界） 既知の攻撃と機械的な大量攻撃をフィルターする 26

レイヤー1 入口：WAFと境界の対策（1） レイヤー1の役割は、既知の攻撃と大量の機械的な攻撃をふるい落とし、後続レイヤーの負担を減らすことです。 基本的に「ここで全てを止められる」とは考えてはいけません。 • WAFのマネージドルールを使う： AWSが提供するルール群（一般的な脆弱性、既知の不正入力、悪質なIPアドレスなど）を有効にします。新しい 攻撃手法が見つかるとAWS側で更新されるため、自社で追いかける負担が減ります。 • レート制限： 同じ相手からの短時間の大量アクセスを制限し、ログイン画面への総当たり攻撃や一括取得を抑えます。 • WAFを迂回させない： 例えば、CloudFrontにだけWAFを適用し、その背後にALB（ロードバランサー）を置く構成では、ALBへの 直接アクセスがCloudFront側のWAFを迂回します。自社のCloudFrontを経由する通信だけをALBに通 すなどの対策が必要です。 27

レイヤー1 入口：WAFと境界の対策（2） • DDoS対策： AWS Shieldで大量の通信による妨害を緩和します。 • 仮想パッチの手順を用意する： ゼロデイの脆弱性が公表されたとき、アプリを修正するまでの間、WAFに専用ルールを追加して一 時的に防ぐ手順を決めておきます。 • 管理画面を公開しない： 管理用の画面やAPIはインターネットに出さず、VPNや社内経路からのみ使えるようにします。 ただし、本資料では詳しく触れませんが、VPN自体に脆弱性がある可能性などもあるため、 AWS だけでなく、総合的なセキュリティ対策が必要です。 28

レイヤー1 入口：利用者を限定する場合 • 利用者を限定する（社内専用のシステムの場合）： 利用者が社内に限られるシステムでは、送信元IPアドレスの制限で不特定多数からの接続を断ちます。 ただし、IPアドレス制限のみで安心してはいけません。 許可したネットワーク内の端末が乗っ取られた場合や、来客用Wi-Fiなどが許可済みの送信元IPアドレスを共有している場 合は、IP制限だけでは不正アクセスを防げません。 この場合、攻撃者が「許可された場所」から来るためです。盗まれた認証 情報が、こうした許可済みの経路から使われる場合も同様です。 • クライアント証明書で接続元を確認する： ALBの相互TLS（mTLS）の検証モードを使うと、信頼する認証局が発行した有効なクライアント証明書と、それに対応する 秘密鍵を持つ接続元にアクセスを限定できます。 IPアドレスが同じでも、必要な証明書と秘密鍵がなければ接続できません。 証明書の配布・更新・失効はMDMなどで管理します。秘密鍵については、対応端末ではTPMなどのセキュリティチップで生 成・保護する設定を検討します。MDMで証明書を配布するだけで、秘密鍵がセキュリティチップに保存されるとは限りませ んので注意してください。 29

参考となる資料：レイヤー1 • AWS Managed Rules ルールグループ一覧（AWS WAF 開発者ガイド）： AWSが管理するルール群の一覧です。本番適用前にテストと調整を行うよう求めています。 • Application Load Balancer へのアクセスの制限（Amazon CloudFront 開発者ガイド）： CloudFront経由のアクセスだけをALBに通す方法（カスタムヘッダー、CloudFront用マネージドプレフィックスリスト）を説明し ています。 • ELB Best Practices: Infrastructure Protection（AWS）： AWS WAFのレートベースルールやIP評価リストの活用に加え、DDoS対策としてロードバランサーとCloudFrontなどを組み合 わせることを推奨しています。 • OWASP Virtual Patching Cheat Sheet： 修正版を適用するまでの間、WAFなどで攻撃を一時的に防ぐ「仮想パッチ」の考え方と手順です。 • Configuring mutual TLS on an Application Load Balancer（Elastic Load Balancing ユーザーガイド）： 検証モード（verify）では、ALBが接続時にクライアント証明書を検証することを説明しています。2023年11月に提供が始まった 機能です。 30

• https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-list.html
• https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html
• https://aws.github.io/aws-elb-best-practices/security/infrastructure_protection
• https://cheatsheetseries.owasp.org/cheatsheets/Virtual_Patching_Cheat_Sheet.html
• https://docs.aws.amazon.com/elasticloadbalancing/latest/application/configuring-mtls-with-elb.html

レイヤー2 アプリケーションとソフトウェアサプライチェーン 脆弱性を作らない、ライブラリの脆弱性を素早く修正する 31

レイヤー2 安全なコードの書き方 アプリ自身で不正な入力や操作を拒否し、データや機能を守るレイヤーです。自社のコードだけでなく、利用するライブラリやフ レームワークの脆弱性も、重大な被害につながることがあります。 • SQLはプレースホルダで組み立てる： 入力値を文字列連結でSQLに埋め込まず、パラメータとして渡します。ORM（オブジェクト関係マッピング / Object-relational mapping）を使用していても、手 書きSQLの部分で連結していれば危険です。 • 入力を検証し、出力先に応じた安全な処理を使う： 入力時には型、長さ、許可する文字を検証（バリデーション）して不正な値を拒否します。画面表示では、出力先の文脈に応じたエスケープを行います。SQLにはプ レースホルダを使います。OSコマンドの呼び出しは可能な限り避け、専用のAPIで処理します。 • 利用者ごとに操作とデータへのアクセスを確認する： ログイン済みであっても、すべてのデータや機能を使えるようにはしません。要求を受けるたびに、その利用者が対象のデータを参照・変更してよいかをサーバ側で 確認します。画面上でボタンを隠すだけでなく、URLやデータのIDを書き換えても、他人・他社の情報にアクセスできないようにします。 • エラー時に内部情報を出さない： エラー画面にスタックトレースやSQL文を表示しないようにします。 • 不要な機能を公開しない： デバッグ用や監視用のエンドポイントを本番で外部に公開しないようにします。 32

レイヤー2 ライブラリと開発工程の管理 • 依存ライブラリを継続的に検査する（SCA）： 使用しているライブラリに既知の脆弱性がないか、ツールで自動的に検査します。 • SBOM（Software Bill of Materials） を作る： どのソフトウェアのどのバージョンを使っているかの一覧（SBOM / ソフトウェア部品表）を作り、更新しておきます。新しい脆弱性が公表さ れたとき、該当する部品を使っているシステムを素早く調べられます。 実際に影響を受けるかは、その部品の利用方法や設定なども確認して判断します。 • 自動テストに組み込む： コードの静的解析（SAST）とライブラリ検査（SCA）を、リリース前の自動処理に組み込みます。動作中のアプリへの検査（DAST）は検証環境 で定期的に行います。 • 修正の期限を決める： 「深刻度が高い脆弱性は何日以内に修正する」というルールを決め、守れているかを記録します。 • 開発基盤の防御： ソースコード管理やリリースの仕組みにもMFAと権限管理を適用します。ここが乗っ取られると、正規のリリースとして不正なコードが配布さ れます。 33

参考となる資料：レイヤー2 • OWASP Top 10:2025（日本語版）： ウェブアプリケーションの重大リスクの最新版です。 2025年版では、2021年版の「脆弱で古くなったコンポーネント」を拡張した「ソフトウェアサプライチェーンの不備」が3位に入り、「例外的な 状況への不適切な対応」が10位に新設されました。また、「セキュリティ設定の不備」は5位から2位に上がりました。 本セクションでは、これらに加えて、1位の「アクセス制御の不備」への対策も重視します。ただし、実際に着手する順番は、順位だけでなく、自 社システムの構成や扱うデータ、現在の対策状況を踏まえて決定します。 • A03:2025 Software Supply Chain Failures（OWASP）： 利用部品とその依存関係を継続的に棚卸しし、検査ツールで監視することを求めています。 • 安全なウェブサイトの作り方（IPA）： SQLインジェクションなどの根本的な解決策を示す国内の定番資料です。別冊「安全なSQLの呼び出し方」で、プレースホルダの使用を解説し ています。 • ソフトウェア管理に向けたSBOMの導入に関する手引 ver2.0（経済産業省、2024年8月）： SBOMの作成・運用方法と、SBOMを使った脆弱性管理の手順をまとめています。 34

• https://owasp.org/Top10/2025/ja/
• https://owasp.org/Top10/2025/A03_2025-Software_Supply_Chain_Failures/
• https://www.ipa.go.jp/security/vuln/websecurity/about.html
• https://www.meti.go.jp/policy/netsecurity/wg1/SBOMv2.pdf

レイヤー3 実行環境（コンテナ・サーバ） 仮に乗っ取られても、サーバ上でできることを減らす 35

レイヤー3 実行環境の対策（1） アプリの脆弱性を突かれて、攻撃者がサーバ上で命令を実行できる状態になった場合に、できることを減 らすためのレイヤーです。 • 一般ユーザー権限で動かす： アプリを管理者（root）権限で動かさないようにします。コンテナの場合は、実行ユーザーを非rootに指定し、特権モードを使いません。EC2 上でアプリを直接動かす場合は、専用の一般ユーザーで実行します。 • ファイルを書き換えられないようにする： コンテナのルートファイルシステムを読み取り専用にし、攻撃ツールの設置や設定の改ざんを難しくします。処理に必要な書き込み領域は別途 用意し、範囲を最小限にします。自社で管理するEC2でも、アプリが書き込める場所を限定し、改ざん検知を組み合わせます。 • 余計なものを入れない： コンテナには最小限のベースイメージを使い、動作に不要なシェルや開発用ツールを本番イメージに含めません。自社で管理するEC2も最小 構成のAMIを使い、不要なパッケージやサービスを削除・無効化します。これにより、攻撃される箇所と、侵入後に攻撃者が使える道具を減ら します。 36

レイヤー3 実行環境の対策（2） • 修正済みのイメージで入れ替える： 稼働中の環境を直接修正するのではなく、修正済みのイメージを作って入れ替えます。構成を一定に保つことで、改ざんの検知や復旧をしや すくします。 コンテナの場合は新しいイメージで作り直し、ECSではそのイメージを指定してタスクを入れ替えます。 自社で管理するEC2の場合は、修正済みのAMIを作り、Auto Scalingなどでインスタンスを入れ替えます。 • イメージを検査する： コンテナイメージは、Amazon ECRに登録し、Amazon Inspectorによる拡張スキャンなどで脆弱性を継続的に検査します。 自社で管理するEC2は、稼働中のインスタンスをInspectorで検査し、AMIはEC2 Image Builderで作成時に検査する仕組みを組み込 みます。 • OSやミドルウェアを更新する： コンテナの場合は、ベースイメージやイメージ内のパッケージを更新し、新しいイメージを作って入れ替えます。 ECSでFargateを使う場合、ホスト側のOSはAWSが管理・更新します。自社で管理するEC2上で動かす場合は、ホスト側のOSも更新対象 とし、Systems Managerなどで修正の適用を自動化するか、修正済みのAMIで入れ替えます。 37

参考となる資料：レイヤー3 • NIST SP 800-190 Application Container Security Guide（NIST、2017年9月）： コンテナ特有のリスクと、イメージの検査、最小構成、変更せずに入れ替える運用などの対策を示しています。 • Amazon EC2 container instance security considerations（Amazon ECS 開発者ガイド）： タスクを管理者権限で動かさないことを推奨しています。 38

• https://csrc.nist.gov/pubs/sp/800/190/final
• https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ec2-security-considerations.html

レイヤー4 AWSアカウントと権限管理 奪われた権限でAWS全体へ広がるのを防ぐ 39

レイヤー4 プログラムの権限 サーバが乗っ取られると、攻撃者はアプリに与えられた権限を悪用して、AWS上のデータやサービスを操作する可能性があります。権限を必要最 小限に絞ることで、被害が及ぶ操作やリソースの範囲を小さくできます。ただし、業務上アクセスを許可しているデータや連携先への被害は残るた め注意してください。 • ロールを最小権限にする： アプリに付ける権限（IAMロール）は、必要なサービス、必要な操作、必要なリソースに限定します。「S3すべてへのフルアクセス」ではなく「このバケットのこのフォルダ の読み取りのみ」とします。 • 役割ごとにロールを分ける： Webアプリ、バッチ処理、外部サービス連携で別々のロールを使い、それぞれに必要な権限だけを与えます。さらに、他の処理の認証情報を取得したり、別のロールを 引き受けたりできないようにします。特に同じEC2上で複数のコンテナを動かす場合は、ロールの分離に加えて、実行環境や認証情報の取得経路の分離も確認します。 • 認証情報の取得経路を守る： EC2ではIMDSv2を強制し、SSRF（本来は外部からアクセスできない内部システムやクラウドの管理画面などにサーバ側から不正なリクエストを送信させる脆弱性お よび攻撃手法）で認証情報を盗まれにくくします。コンテナ（ECS）の場合は、コンテナからホスト側の認証情報を取得できない設定にします。 • 秘密情報を専用サービスで管理する： DBのパスワードや、連携先サービスのAPIキーなどの認証情報はSecrets Managerなどに保管し、ソースコードや設定ファイル、コンテナイメージに書き込みません 。連携先が対応する更新方法を確認し、可能なものは定期的な更新を自動化します。更新時は、保管した認証情報と接続先の認証情報を同期させます。 40

レイヤー4 人の権限とアカウント構成 • 用途ごとにAWSアカウントを分ける： 本番、開発、ログ保管、セキュリティ監視を別アカウントにします。ログ保管アカウントには、本番側からログを削除・変更できる権限を与えず、 必要に応じて保存期間中の削除を防ぐ設定も組み合わせます。アカウントを分けるだけでなく、アカウント間の権限も制限することが重要で す。 • 組織全体で禁止操作を決める： AWS Organizationsのサービスコントロールポリシー（SCP）で、対象のメンバーアカウントに対し、「ログの停止」「監視サービスの無効化」 「許可していないリージョンの利用」などを制限します。対象アカウントでは、管理者権限やrootユーザーでも、この制限を越えて操作できま せん。ただし、Organizationsの管理アカウントやサービスリンクロールなどには適用されないため、それらは別途保護します。 • 人のログインを一元化する： IAM Identity Centerでシングルサインオンにし、多要素認証（MFA）を必須にします。長期間有効なアクセスキーは発行しません。 • rootユーザーを使わない： rootユーザーにはMFAを設定し、日常の作業には使いません。 41

参考となる資料：レイヤー4 • Security best practices in IAM（AWS）： プログラムには一時的な認証情報（IAMロール）を使うこと、最小権限、rootユーザーの保護、人のアクセスにIAM Identity Centerと MFAを使うことを推奨しています。 • Amazon EC2 container instance security considerations（Amazon ECS 開発者ガイド）： タスクに最小権限のロールを付けることを推奨しています。また、EC2上でawsvpcネットワークモードを使うタスクでは、 ECS_AWSVPC_BLOCK_IMDSをtrueに設定し、ホストのインスタンスプロファイル認証情報へのアクセスを遮断する方法を示しています。 • Multi-account strategy for small and medium businesses（AWS ブログ）： ログ保管用（Log Archive）とセキュリティ用（Security Tooling）のアカウントを分ける構成を説明しています。 • Organizing Your AWS Environment Using Multiple Accounts（AWS ホワイトペーパー）： 同様のアカウント分割と、組織単位のポリシーによる統制を説明しています。 • AWS Well-Architected フレームワーク セキュリティの柱： アイデンティティ管理の領域で、秘密情報を専用の仕組みで保管・利用することを求めています。 42

• https://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPractices.html
• https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ec2-security-considerations.html
• https://aws.amazon.com/blogs/mt/multi-account-strategy-for-small-and-medium-businesses/
• https://docs.aws.amazon.com/pdfs/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.pdf
• https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/welcome.html

レイヤー5 ネットワーク内部と外向き通信 攻撃の横展開と、外部へのデータ持ち出しを防ぐ 43

レイヤー5 内側の区切り WAFを突破されても、ネットワークの区切りで攻撃者が動ける範囲を限定します。見落とされがちですが、外へ 出ていく通信を絞ることは、データ持ち出しの経路を減らす重要な対策です。 • サーバとDBをプライベートサブネットに置く： インターネットから直接届かない場所に配置し、外から入れるのはロードバランサーだけにします。 • セキュリティグループで通信相手を限定する： 「ロードバランサー→アプリ」「アプリ→DB」のように、必要な組み合わせだけを許可します。IPアドレスではな く、セキュリティグループ同士の参照で指定すると管理しやすくなります。 • 役割ごとにサブネットやVPCを分ける： 公開用、アプリ用、DB用、外部サービス連携用を分け、互いに必要な通信だけを許可します。 44

レイヤー5 外向き通信の制限（1） • セキュリティグループの外向きルールを絞る： 初期設定では外向きの通信がすべて許可されています。必要な宛先とポートだけに変更します。 • インターネットへの出口を許可リスト方式にする： 外部APIなどへの通信は、AWS Network Firewallやプロキシで、業務に必要な宛先・ドメインに限定しま す。乗っ取られたサーバから、許可していない外部の宛先へ新たに接続する経路を減らせます。ただし、許可済 みのサービスや通常のWeb応答を使ったデータ持ち出しまで防げるわけではありません。 • DNSによる持ち出しを防ぐ： Route 53 Resolver DNS Firewallで、不審なドメインへの問い合わせを遮断します。DNSの問い合わせ にデータを埋め込んで送り出す手口への対策となります。 45

レイヤー5 外向き通信の制限（2） • AWSサービスへインターネットを経由せず接続する： S3などへはVPCエンドポイント経由で接続します。さらにエンドポイントポリシーで「自社のバケットだけ」に限 定します。限定しないと、攻撃者が自分のバケットへデータをコピーする経路として使えてしまいます。 • 許可した通信経路にもリスクが残ることを理解する： 外向き通信の許可リストには、連携先の主要システムが含まれます。そのため、乗っ取られた自社システムから 主要システムへの不正な操作は、宛先の制限だけでは防げません。こちらはレイヤー7の権限制限や認証情報 の無効化などで対策します。 また、攻撃者がWebアプリへの要求に対する応答としてデータを受け取る経路も残ります。セキュリティグ ループは、許可した受信通信への応答を、外向きルールにかかわらず許可します。アプリの認可、返すデータの 制限、大量取得の検知も組み合わせます。 46

参考となる資料：レイヤー5 • AWS Networking Best Practices: Outbound（AWS）： 制限のない外向き経路が、データ持ち出しや攻撃者サーバとの通信を許す最も一般的な要因だとしています。DNS Firewallを主なドメインフィルター、Network Firewallを最後の防壁として併用する構成を推奨しています。 • Secure your Amazon VPC DNS resolution with Route 53 Resolver DNS Firewall（AWS ブログ）： Network Firewallやセキュリティグループでは、Route 53 Resolverへの問い合わせを検査できず、DNS経由の持ち 出しが残ることを説明しています。 • Preventing data exfiltration in a private VPC（AWS）： VPCエンドポイントポリシーで接続先を自社のバケットに限定し、利用者が自分のバケットへデータを持ち出すのを防ぐ手順 です。 • AWS Well-Architected フレームワーク セキュリティの柱： インフラストラクチャ保護の領域で、ネットワークを層に分け、各層の通信を制御することを求めています。 47

• https://aws.github.io/aws-networking-best-practices/security/outbound/
• https://aws.amazon.com/blogs/networking-and-content-delivery/secure-your-amazon-vpc-dns-resolution-with-amazon-route-53-resolver-dns-firewall
• https://docs.aws.amazon.com/res/latest/ug/S3-buckets-preventing-exfiltration.html
• https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/welcome.html

レイヤー6 データ保護 盗めるデータを減らし、盗んでも使えなくする 48

レイヤー6 データの分離 攻撃者がDBやストレージに届いてしまった場合に、盗めるデータを少なくし、盗んでも使えないようにし、盗み出 しを遅く・目立つようにするレイヤーです。 • 重要度ごとに置き場所を分ける： 最重要の情報は、通常の業務データとは別のDB、別のスキーマ、場合によっては別のAWSアカウントに置きま す。普段の業務処理からは直接読めない場所にすることで、アプリが乗っ取られても届きにくくなります。 • トークン化する： 業務データの中では、個人情報そのものの代わりに意味を持たない識別子（トークン）を使い、本物の値は別の 保管庫で管理します。 • 本番データを開発・検証環境にコピーしない： どうしても必要な場合は、個人情報をマスキングまたは架空の値に置き換えてから使います。 49

（参考）ハッシュ化と暗号化の違い パスワードの「ハッシュ化」と、個人情報の「暗号化」は、目的も仕組みも違います。混同されやすいので、先に整理します 。 ハッシュ化 暗号化 元に戻せるか 戻せない（一方通行の変換） 鍵があれば戻せる（復号できる） できること 入力値から同じ方式・設定でハッシュ値を計算し、保 元の値を取り出して表示・編集できる 存したハッシュ値と照合する 向いているデータ パスワード 氏名や住所など、表示や編集が必要な個人情報 守りの要 計算を遅くする設定とソルト 鍵の保管場所と、鍵を使える処理の限定 OWASPも、ハッシュ化は一方通行なので照合に向き、暗号化は双方向なので画面に表示する住所のようなデータに使 える、と整理しています（OWASP Password Storage Cheat Sheet）。表示が必要な項目をハッシュ化すると、 元の値を二度と取り出せなくなりますので注意してください。 50

個別暗号化で受け入れる制約 氏名や住所を項目ごとに暗号化する（アプリケーションレベル暗号化）対策は有効です。ただし、次の制約を受け入れる必要があ りますので設計段階での精査が必要です。 • DB側での検索や並べ替えに制約が生じる： 通常の暗号化では、暗号文のまま部分一致検索や五十音順の並べ替えはできません。対応するDB機能などを使う場合は、利用条件と制約を確認します。部分一致検索 が必須の項目では、検索に対応する方式の検討が必要です。 • 鍵の管理が必要になる： 鍵はKMSなどDBとは別の場所で管理し、復号できる処理（ロール）を限定します。鍵を失うとデータも読めなくなるため、鍵の保護と復旧の手順が重要です。 • 処理と実装の負荷が増える： 読み書きの際に暗号化と復号の処理が加わります。実装にはAWS Encryption SDKなどのライブラリを利用し、データを暗号化する「データ鍵」を、KMSなどの別の 鍵で保護するエンベロープ暗号化を検討します。エンベロープ暗号化はデータ鍵の使い回しを意味するものではなく、AWS Encryption SDKは、既定では暗号化操 作ごとに新しいデータ鍵を生成します。 性能上の理由で鍵を再利用する場合は、利用期間や処理量などの上限を設け、安全性を確認します。暗号文は元の値より長くなるため、保存する列の長さも見直しま す。 • アプリ自体の乗っ取りは防げない： DBのダンプやバックアップが流出しても、鍵がなければ読めません。一方、復号の権限を持つ処理が乗っ取られると復号されてしまうため、復号できる処理の限定と、 大量の復号を検知する監視を組み合わせます。 51

DB製品が提供する暗号化機能という選択肢 DB製品が提供する機能を利用して、項目単位の暗号化を実現する方法もあります。 例えばSQL ServerのAlways Encryptedは、基本的にはアプリ側の対応ドライバーが データを暗号化してDBへ送り、取得時に復号する仕組みです。暗号化処理をアプリに直接 実装する負担を抑えられる場合があります。 ただし、対応ドライバー、鍵の管理方法、利用できる検索やSQLの制約を確認して採用しま す。 52

項目ごとの使い分けの例 項目の例 よくある扱い パスワード ハッシュ化（照合だけできればよい） カード番号 自社で持たない（決済代行会社のトークンを使う） 本人確認書類の番号、生年月日 個別暗号化（検索が不要で、漏れたときの影響が大きい） 住所 個別暗号化しやすい（部分一致検索が不要な場合が多い） 氏名、電話番号 検索の種類で判断する。完全一致検索なら、個別暗号化と検索用の鍵付きハッシュ（HMAC）の併 用を検討する。部分一致検索などが必要な場合は、対応方式と制約を確認して保護方法を選ぶ この表は一般的な判断の例です。実際には「必要な検索の種類」と「漏れたときの影響の大きさ」を踏まえ、項目ごとに 決めます。 53

暗号化は「何から守るか」で選ぶ 暗号化には種類があり、守れる相手がそれぞれ違います。特に「ストレージ暗号化をしているから安心」という誤解が多いので 注意が必要です。 種類 内容 守れるもの 守れないもの 通信の暗号化 TLSで通信を暗号化する 通信経路での盗聴 通信の両端での盗み見 ストレージ暗号化 KMSでディスクやスナップショットを 暗号化された媒体やスナップ SQLインジェクションや、乗っ取られ 暗号化する ショットが、復号に必要な鍵や権 たアプリからの読み出し（自動で復 限なしに持ち出された場合 号されるため） 鍵を使える処理そのものの乗っ取り アプリケーションレベル暗号 重要な項目だけを、アプリが別の鍵 DBだけが盗まれた場合。鍵の権 化 で暗号化してから保存する 限を持たない処理からの読み出 し DBのデータが流出しても、復号に必要な鍵や権限が奪われていなければ、アプリケーションレベル暗号化が有効です。KMSな どで鍵を管理し、復号できる処理（ロール）を限定します。ただし、その処理自体が乗っ取られた場合の読み出しは防げません。 完全一致検索が必要な項目には、検索用の鍵付きハッシュ（HMAC）を別に持つ方法があります。 54

パスワードのハッシュ化：方法による強度の違い パスワードはハッシュ化して保存しますが、「ハッシュ化しているから安全」とは限りません。どの方法 でハッシュ化するかで、漏えいしたときの解読されにくさが大きく変わります。 ハッシュは元に戻せませんが、攻撃者は候補のパスワードを次々にハッシュ化し、保存値と一致するも のを探します（総当たりや、他サイトから漏れたパスワード一覧の利用）。 そのため、1回のハッシュ計算を意図的に重くして、推測の回数を稼げなくすることが防御の中心に なります（OWASP Password Storage Cheat Sheet）。 55

パスワード保存方法の比較と推奨度 保存方法 漏えいしたときに起きること パスワード保存方法とし ての評価 平文 そのまま読まれる 問題外 可逆暗号化 鍵も盗まれると全件が復元される 問題外 高速ハッシュ（MD5、SHA-1、SHA- 事前計算した対応表（レインボーテーブルなど）を使い回せるため、多 不可 256など）、ソルトなし 数のパスワードを効率よく推測される。同じパスワードの利用者も判 別される 高速ハッシュ＋ソルト 事前計算した対応表（レインボーテーブルなど）は使えないが、計算が 不可 速いためGPUなどで大量に推測でき、弱いパスワードは短時間で解 読される 計算を遅くした専用ハッシュ（PBKDF2 1回の計算を意図的に遅くし、総当たりの時間と費用を大きくする 条件付きで可 メモリも大量に使う専用ハッシュ（ 計算時間に加えて大量のメモリを要求し、GPUや専用ハードウェアに 推奨 scrypt、Argon2id） よる並列攻撃も難しくする 、bcrypt） 56

「問題外」「不可」「条件付きで可」の意味 • 「問題外」は、漏えいした時点でパスワードがそのまま、または鍵があれば復元できてしまうため、選択肢 になりません。 • 「不可」は、現在ではパスワードの保存方法として使うべきではないという意味です。SHA-256などの 方式そのものは、改ざん検知などの用途では安全に使えます。 • 「条件付きで可」は、適切な設定で使う場合に限り使用してよい、という意味です。 • PBKDF2は、FIPS 140準拠が求められる場合の選択肢です。OWASPはHMAC-SHA-256で60万回以上の反復を推奨していま す。FIPS準拠には、設定値だけでなく、検証済みの暗号モジュールを使用するなどの要件も確認します。 • bcryptは、ワークファクター10以上で使い、入力が72バイトまでしか扱われない点に注意します。 • どちらも現在利用されているパスワード保存方式ですが、弱いパスワードや不十分な設定では推測される可能性があります。既存シス テムでは、設定値や運用状況を確認し、必要な強化や移行を判断します。ただし新規開発では、GPUによる並列攻撃に強いArgon2id を第一に検討してください。 57

OWASPの推奨アルゴリズムと最低設定 アルゴリズム 位置づけ 最低設定の例 Argon2id 第一選択 メモリ19MiB、反復2回、並列度1 scrypt Argon2idが使えない場合 N=2^17（128MiB）、r=8、p=1 bcrypt 既存システム向け ワークファクター10以上。入力は72バイトまで PBKDF2 FIPS 140準拠が必要な場合 HMAC-SHA-256で60万回以上 ※PBKDF2の設定値はOWASPの推奨値です。この設定だけでFIPS 140準拠になるわけではありません。 Argon2idとscryptには、同等の強度でメモリとCPUの配分を変えた設定の組み合わせも示されています。設定値 は計算機の進歩に合わせて改訂されるため、採用時に最新版を確認してください。 58

パスワード：実装と運用のポイント（1） • ソルト： 利用者ごとに異なるランダムな値（ソルト）を加えてからハッシュ化します。同じパスワードでも保存値が変わり、対応 表による一括解読を防げます。ソルトを自動生成・管理するパスワード保存用ライブラリを利用します。ソルトの指定 が必要なAPIを使う場合は、暗号学的に安全な乱数で生成し、ハッシュ値とともに保存します。ハッシュ方式そのもの は自作しません。 • ペッパー： 全利用者で共通の秘密の値（ペッパー）を加える方法もあります。ペッパーはDBとは別の場所（Secrets Manager やKMSなど）に保管するので、SQLインジェクションやバックアップ流出でDBだけが盗まれても解読が難しくなりま す。 • ペッパーが漏えいした場合は交換し、影響を受ける利用者にパスワードの再設定を求めます。次回ログイン時の再計算だけでは、既に流 出したハッシュ値と古いペッパーを使った解析を止められません。ハッシュ値を暗号化して保存する方式では再暗号化による鍵交換が できますが、古い暗号文と鍵が流出した場合の危険は残ります。 59

パスワード：実装と運用のポイント（2） • ワークファクターを調整する： 計算の重さを決める設定値です。OWASPは、サーバの性能に合わせて1回の計算が1秒未満に収まる範囲で 決めるとしています。重くしすぎると、大量のログイン要求でCPUを使い切らせるサービス妨害に悪用される おそれがあります。 • 定期的に強化する： 計算機の性能向上に合わせて設定を引き上げます。利用者が次にログインしたときに、新しい設定で再ハッシ ュ化するのが一般的です。 • 方式と設定値を一緒に保存する： $argon2id$v=19$m=19456,t=2,p=1$... のようなPHC文字列形式で保存すると、将来の方式変更 時に新旧を混在させて段階的に移行できます。 60

パスワード：実装と運用のポイント（3） • 古い方式から移行する： MD5やSHA-1で保存している場合は、次回ログイン時に新方式で再ハッシュ化します。長期間ログイン のない利用者は、古いハッシュを削除してパスワードの再設定を求める方法があります。 • 自作しない： 言語やフレームワークが提供する実装を使います。例として、JavaのSpring Securityには Argon2PasswordEncoder や BCryptPasswordEncoder があります。 • そもそも持たない： 外部のIDプロバイダーによるログインやパスキーを使えば、自社でパスワードを保存する必要自体がな くなります。システムの用途、利用ユーザー層によっては有効な選択肢です。 61

一括コピーを難しくする（1） 攻撃者の多くは、侵入後にデータをまとめて持ち出そうとします。それを難しくし、試みたら気づけるよう にします。 • 用途ごとにDBユーザーを分ける： 参照だけの処理には読み取り専用のユーザーを使い、テーブルの削除や変更の権限は与えません。 • 必要な項目だけを返す： アプリからはビューなどを通して、業務に必要な列だけを読めるようにします。 • 一度に取得できる件数を制限する： APIや画面で、1回に返す件数とページ送りの上限を決めます。全件を一度に取得できる機能は作らな いか、承認制にします。 62

一括コピーを難しくする（2） • 大量取得を検知する： DBの監査ログで、通常と比べて大量の読み出しや、普段使われない時間帯のアクセスを検知します。 • おとりデータを置く： 実在しない顧客情報や識別子などのおとりデータを用意し、不審なアクセスや外部での使用を検知する方法が あります。ただし、データを置くだけでは警告は出ないため、監視する仕組みが必要です。正規の集計・保守な どで触れないように設計し、誤検知がどの程度発生するかを確認して運用します。 • 外へ出す経路を絞る： レイヤー5の外向き通信制限と組み合わせ、読み出したデータを外部へ送る経路を減らします。ただし、通常の Web応答や許可済みサービスを使った持ち出しは残るため、取得できるデータの範囲や量の制限、監視も併 用します。 63

バックアップを守る • 別アカウントに保管する： バックアップは本番とは別のAWSアカウントにコピーします。 • 保持期間中の削除や保護設定の解除を防ぐ： AWS BackupのVault Lockを使い、バックアップの保持期間中の削除や、保持期間を短くする変更を防ぎ ます。管理者にもロックを解除できない保護が必要な場合は、コンプライアンスモードを使用し、猶予期間の終 了後にロックが確定していることを確認します。ガバナンスモードは、必要な権限を持つ利用者が解除できま す。 • 復元を試しておく： 定期的に実際に復元し、手順と所要時間を確認します。 • 共有設定を確認する： スナップショットが意図せず外部や公開状態で共有されていないかを、定期的に確認します。 64

参考となる資料：レイヤー6 • OWASP Cryptographic Storage Cheat Sheet： 暗号化はアプリケーション、DB、ファイルシステム、ハードウェアの各層で行えると整理しています。ハードウェア層の暗号化は物理的な盗難に は有効でも、遠隔からサーバを侵害された場合は防げないとしています。暗号化の比較表はこの整理に基づいています。 • OWASP Password Storage Cheat Sheet： パスワード保存のアルゴリズム、推奨設定、ソルトとペッパーの根拠です。 • 安全なウェブサイトの作り方（IPA）： 改訂第7版で、パスワードをソルト付きハッシュ値で保存し、漏えい時の復元を困難にする対策を示しています。 • OWASP API Security Top 10 2023: API4 Unrestricted Resource Consumption： 1回に取得できる件数（ページサイズ）の上限設定などを求めています。 • AWS Backup Vault Lock（AWS Backup 開発者ガイド）： コンプライアンスモードでは、猶予期間が終了するとロックを解除できなくなり、保持期間中のバックアップの削除や保持期間の短縮を防げる と説明しています。ガバナンスモードとの違いも示しています。 ※ 今回紹介した「おとりデータ（ハニートークン）」は実務で広く使われる手法ですが、特定の標準文書に基づく推奨ではありません。 65

• https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html
• https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
• https://www.ipa.go.jp/security/vuln/websecurity/about.html
• https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/
• https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html

レイヤー7 外部システムとの連携 自社システムの侵害を外部システムへ広げない 66

レイヤー7 外部システムとの連携の目的 自社システムが侵害されても、外部システムへ被害を広げないことを目的とします。 基本的な考え方は、「自社システムを、外部システムにとって無条件に信頼できる相手として は扱わない」ことです。 67

レイヤー7 接続の制限が効かない場面を理解する 外部システム側の送信元IPの制限とAPIの認証情報は、無関係な第三者からの接続を防ぐには有効です。ただ し、外部システムへの接続経路と認証情報を利用できる処理が乗っ取られると、攻撃者も次の2つを使って接続 できるおそれがあります。 • 許可されたIPアドレス（乗っ取ったサーバ自体から接続するため） • 自社システムに保存されているAPIの認証情報（APIキー、トークン、クライアント証明書と対応する秘密鍵など） そのため、このレイヤーの焦点は「接続を防ぐ」ことから「接続されても被害を小さくする」ことへと移行します。 68

レイヤー7 自社で管理できること（1） • 認証情報を守る： APIの認証情報は、コンテナイメージや設定ファイルに置かず、Secrets Managerなどで管理します。読み 取れるロールは連携処理だけに限定し、定期的に更新します。 • APIの権限を絞る： 連携用のアカウントやAPIキーには、連携に必要な操作とデータだけを許可します。参照だけでよい連携には 書き込み権限を与えず、全データを一括で取得できる権限も避けます。 • 連携処理を分ける： 外部システムへの接続は専用の連携処理（バッチなど）だけが行い、画面を提供するWebアプリから直接接続 しない構成にします。Webアプリが乗っ取られても、認証情報に届きにくくなります。 • 外部システムからの受け口を最小にする： 外部システムから自社システムへの通知（Webhookなど）を受ける場合は、受け口を送信元で限定し、署名な どで送信元を確認します。 69

レイヤー7 自社で管理できること（2） • 受け取ったデータを検証する： 外部システムから受け取ったデータも、第三者からの入力と同じように、形式や値の範囲を検証し てから使います。連携先が侵害された場合に、不正なデータで自社システムが攻撃されるのを防ぐ ためです。 • 連携するデータを最小にする： 外部システムから取得して自社システムに保存するデータは、処理に必要な項目と期間だけにしま す。 • 自社システムからの通信を監視する： 外部システムへのリクエストの種類、件数、時間帯を記録し、普段と違う動きを検知できるようにし ます。 70

レイヤー7 事業者に確認・依頼すること 外部システムの基盤やサービス自体の防御は、主に事業者が管理します。利用者側で変更できる設定と、事業者 への依頼が必要な対策を確認します。 • 権限の細かさ： APIの権限を、操作やデータの範囲でどこまで細かく絞れるか。 • 即時の無効化： 侵害が疑われたときに、連携用の認証情報をすぐに無効化し、再発行できるか。その手順と連絡先。 • ログの提供： 自社システムからのアクセスの記録（いつ、どのAPIで、何件）を確認できるか。 • 連絡体制： 事業者側で不審なアクセスを検知したときに連絡してもらえるか。自社が侵害を疑ったときの連絡窓口はどこか。 • 事業者のセキュリティ対策： 第三者認証（ISMSなど）の取得状況や、脆弱性への対応方針。 71

参考となる資料：レイヤー7 • OWASP API Security Top 10 2023: API10 Unsafe Consumption of APIs： 開発者は外部APIから受け取ったデータを利用者の入力より信用しがちで、特に有名な事業者のAPIではその傾向 が強いと指摘しています。連携先から受け取ったデータは、使う前に必ず検証するよう求めています。 • NIST SP 800-207： ネットワーク上の位置だけを根拠に信頼を与えない、というゼロトラストの原則です。「自社システムを無条件に信頼 できる相手として扱わない」という本セクションの前提は、この原則によります。 • 中小企業のためのクラウドサービス安全利用の手引き 説明資料（IPA、2026年6月）： クラウドサービスは提供者と利用者が連携して運用するものであり、利用者が対応すべき対策を理解して実施するよ う求めています。事業者が信頼できるかの確認も、選定時の確認点に挙げています。 ※「接続の制限が効かない場面」の整理、連携処理の分離、事業者への確認項目は、上記の原則を元にした設計判断です。特定の文書でこの形が 指定されているわけではありません。 72

• https://owasp.org/API-Security/editions/2023/en/0xaa-unsafe-consumption-of-apis/
• https://csrc.nist.gov/pubs/sp/800/207/final
• https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0_app_cloudservice.pdf

レイヤー8 検知と対応 全てのレイヤーを監視し、素早く気づいて止める 73

レイヤー8 記録を残す 侵入を完全に防ぐことはできないため、入られたことに早く気づき、被害が広がる前に止めることが重要です。被 害の大きさは、攻撃者が持つ権限やアクセスできるデータの範囲にも左右されますが、気づくのが早いほど、拡大 を抑えられる可能性が高まります。 • 必要な操作ログを漏れなく記録する： AWS CloudTrailで、全リージョンの管理イベントを記録します。S3のオブジェクト取得などのデータイベントは既定では記録 されないため、監視するリソースと操作を決めて有効にします。CloudTrailだけでOS内のコマンド実行や通常のSQL操作ま で記録できるわけではないため、OS・アプリ・DBのログも組み合わせます。 • 通信とアプリのログを残す： VPCフローログ、WAFログ、ロードバランサーのログ、アプリのログ、DBの監査ログを保存します。 • ログを攻撃者に消させない： ログは別のAWSアカウントに集め、削除や改ざんができない設定にします。侵入者は痕跡を消そうとするためです。 74

レイヤー8 異常に気づく • 脅威検知サービスを有効にする： Amazon GuardDutyで、不審なAPI操作、悪意のある通信先との通信、認証情報の不正利用などを検知します。コンテナ を使う場合は、コンテナ内の不審なプロセス実行を検知するRuntime Monitoringも有効にします。 • 設定の不備を継続的に確認する： AWS Security HubとAWS Configで、公開されたバケットや無効化された暗号化などを検知します。 • 業務の異常を監視する： エラーの急増、大量のデータ取得、普段と違う時間帯のアクセスなど、業務の視点での異常にもアラートを設定します。 • 通知が届く先を決める： アラートが誰に届き、夜間や休日は誰が判断するのかを決めておきます。通知が出ても誰も見ていなければ意味がありません ので確認体制も整備します。 • 連携先の記録も使う： 外部システムの事業者がアクセスの記録を提供している場合は、自社側の記録と突き合わせ、自社システムからの不審なアク セスがないかを確認します。 75

レイヤー8 止める • 自動対処は範囲を決めて使う： 危険度の高い検知があったとき、該当サーバの通信を遮断するなどの一次対応を自動化できます。ただし誤検知でサービスが止まる可能性 があるため、自動にする条件と、人が判断する条件を分けておきます。 • 奪われた権限を確実に止める： ログイン元のユーザーを停止するだけでは、発行済みのIAMロールの一時的な認証情報を止められない場合があります。発行済みセッション の権限を無効にするとともに、侵害された利用者や処理が新しい認証情報を取得できないようにします。 • 通信を遮断して隔離し、調査に必要な情報を保存する： 問題のサーバをすぐ削除すると、原因調査の手がかりが消えます。まず通信を遮断して隔離し、調査に必要な情報を保存してから停止します。 • 連携用の認証情報を無効化する： 自社システムの侵害が疑われたら、外部システムへの連携用の認証情報を、事業者と連携してすぐに無効化し、新しいものを発行します。手順 と連絡先は事前に決めておきます。 なお、検知サービスの通知は数分から十数分かかることがあります。「数秒で自動遮断できる」と期待しすぎず、他のレイヤーで時間を稼ぐ前提で 設計します。 76

参考となる資料：レイヤー8 • AWS Well-Architected フレームワーク セキュリティの柱： 設計原則「トレーサビリティの実現」と「セキュリティイベントに備える」の出典です。インシデント対応の領域では、隔離と調査用デー タの取得を自動化することも求めています。 • Amazon EC2 container instance security considerations（Amazon ECS 開発者ガイド）： GuardDuty Runtime Monitoringでコンテナ内のファイルアクセス、プロセス実行、ネットワーク接続を監視するよう推奨して います。 • Revoke IAM role temporary security credentials（AWS）： ロールの一時的な認証情報を、発行時刻を条件に一括で無効にする方法です。 • Processing GuardDuty findings with Amazon EventBridge（AWS）： 同じ検知の2回目以降は既定で6時間ごとにまとめて通知され、15分または1時間に短縮できると説明しています。続報の通知を早 めたい場合は、この設定の変更も検討してください。 • NIST SP 800-61 Rev. 3（NIST、2025年4月）： インシデント対応を、平時のリスク管理全体の中に組み込むよう求める最新版の指針です。 77

• https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/welcome.html
• https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ec2-security-considerations.html
• https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html
• https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_findings_eventbridge.html
• https://csrc.nist.gov/pubs/sp/800/61/r3/final

運用とガバナンス 持続的な運用と改善で、いざというときに正しく動ける体制を作る 78

継続的な見直し ここまでの対策は、導入した時点で終わりではありません。運用の継続と改善により、いざというときに正 しく動ける体制があって初めて機能します。 • 脆弱性情報を追いかける： 使っているソフトウェアの脆弱性情報を定期的に確認し、深刻度に応じた期限で修正します。最新のSBOMと稼働システム の情報を対応付けておくと、脆弱性のある部品を使っているシステムの特定を効率化できます。実際の影響や修正の優先度 は、その部品の利用方法、設定、外部から到達できるかどうかなども確認して判断します。 • 権限を棚卸しする： 使われていない権限、退職者や異動者のアカウント、古いアクセスキーを定期的に洗い出して削除します。 • 第三者の目で確認する： 年に1回程度、外部の専門家による脆弱性診断やペネトレーションテスト（擬似攻撃）を受けます。 79

事故が起きたときの準備 • 対応手順書を作る： 検知から隔離、調査、復旧、報告までの手順と担当者、連絡先を文書にしておきます。夜間や休日の 判断者も決めます。 • 訓練する： 手順書は、実際に机上で訓練してみると不足が見つかります。年に1回以上、想定シナリオを使って 確認します。 • 外部の支援先を決めておく： 調査（フォレンジック）を依頼できる専門会社を、事故が起きる前に選んでおきます。 80

外部サービス事業者の管理 • 事業者との取り決めを確認する： 侵害時の連絡体制、ログの提供、認証情報の無効化の手順を、契約や運用ルールで確認します（レイ ヤー7を参照）。 • 連携用の認証情報を定期的に更新する： 更新の頻度と手順を決め、更新した記録を残します。 • 事業者の対策状況を定期的に確認する： 第三者認証の更新状況や、事業者が公表する障害・脆弱性の情報を確認します。 81

報告義務を知っておく 個人情報保護法では、要配慮個人情報を含む場合、不正利用による財産的被害のおそれがある場合、不正な目的で行われたおそれがある行為 による場合、本人の数が1,000人を超える場合など、一定の個人データの漏えい・滅失・毀損、またはそのおそれがある事態について、個人情報 保護委員会等への報告と本人への通知が原則として義務になります。 漏えいが確定してから対応を始めるのではなく、報告対象となるおそれを把握した段階から、報告の要否を判断します。 報告の段階 報告期限（速報の日数は目安） 速報 対象事態を知った後、速やかに。目安は概ね3～5日以内 確報 対象事態を知った日から30日以内。不正な目的で行われたおそれがある行為による事態は60日以内 本人への通知は、この表とは別に、事態の状況に応じて速やかに行います。通知が困難な場合には、本人の権利利益を保護するための代替措置 が認められる場合があります。限られた時間で状況を把握できるよう、調査に必要なログをあらかじめ残し、報告・通知の判断者と手順を決めて おくことが重要です。海外の利用者のデータを扱う場合は、GDPRなど関係する法令の適用と報告義務も確認します。 報告期限の出典： 漏えい等の対応とお役立ち資料（ https://www.ppc.go.jp/personalinfo/legal/leakAction/ ） ※報告先は原則として個人情報保護委員会ですが、業種によっては権限が委任された府省庁等になります。 82

• https://www.ppc.go.jp/personalinfo/legal/leakAction/

参考となる資料：運用とガバナンス • NIST SP 800-61 Rev. 3（NIST、2025年4月）： 対応手順の準備、訓練、事後の改善を含むインシデント対応の指針です。 • 漏えい等報告・本人への通知の義務化について（個人情報保護委員会）： 令和4年4月1日から、個人データの漏えい等が発生し、個人の権利利益を害するおそれがあるときは、個人情報保 護委員会への報告及び本人への通知が必要になった旨のアナウンスです。 • ソフトウェア管理に向けたSBOMの導入に関する手引 ver2.0（経済産業省）： 脆弱性情報の継続的な確認と対応の手順です。 • Security best practices in IAM（AWS）： 使われていないユーザーやロール、権限を定期的に見直して削除するよう求めています。 • 中小企業のためのクラウドサービス安全利用の手引き 説明資料（IPA、2026年6月）： クラウドサービスの運用時に、誰が責任を持つかを確認するよう求めています。 83

• https://csrc.nist.gov/pubs/sp/800/61/r3/final
• https://www.ppc.go.jp/news/kaiseihou_feature/roueitouhoukoku_gimuka/
• https://www.meti.go.jp/policy/netsecurity/wg1/SBOMv2.pdf
• https://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPractices.html
• https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0_app_cloudservice.pdf

まとめ 着手の優先順位の目安 84

着手の優先順位の目安（1） 一度にすべてを実施するのは難しいため、次の項目を出発点に、現状の不足と業務への影響を確認して着手順 を決めます。この順番は本資料の目安であり、重大な脆弱性や認証・権限設定の不備がある場合は、その是正を 優先します。 • 1. 持っているデータを見直す： 不要な個人情報の取得と保持をやめます。漏えいした場合の被害を減らすために、優先的に検討したい対策です。業務上の 必要性と、変更に必要な費用・期間を確認して進めます。 • 2. 外部システムとの連携を確認する： 連携用の認証情報の保護、APIの権限、無効化の手順、事業者との連絡体制を確認します。 • 3. 外向き通信を絞る： セキュリティグループの外向きルール、インターネットへの出口、VPCエンドポイントポリシーを見直します。 • 4. 権限を最小にする： アプリのロールと人のアカウントを見直し、秘密情報を専用サービスに移します。 85

着手の優先順位の目安（2） • 5. 記録と検知を整える： ログを別アカウントに保存し、GuardDutyなどの検知と通知先を決めます。 • 6. ライブラリの脆弱性管理を自動化する： 依存ライブラリの検査とSBOMを開発工程に組み込みます。 • 7. 重要データの保護を厚くする： 重要項目の個別暗号化、一括取得の制限、バックアップの保護を進めます。 • 8. 手順書を作り、訓練する： 事故が起きたときの対応手順と報告の流れを決め、実際に試します。 ※この優先順位は、各セクションの資料を踏まえた本資料独自の判断です。費用対効果の見積もりは構成や体制によって変わるため、実際の順 番は現状の棚卸し結果を見て調整してください。 86

ご清聴ありがとうございました

質疑応答・ディスカッションタイム