セキュリティサービス部 佐竹です。
昨年の2025年11月10日に、「AWS におけるランサムウェア対策を考えるために」というブログを投稿致しました。本ブログは先のブログの（特に SCP, RCP に関連した）補足記事となります。
はじめに
上記ブログ「AWS におけるランサムウェア対策を考えるために」は、「ランサムウェア対策のスタート地点での、議論の抜け漏れを無くす」ことを目指して記載したブログとなっています。
その中で「復旧 (Recover)」に関するいくつかの記述をしました。
簡単に方針をまとめると以下の通りになります。
- ランサムウェアはバックアップをも破壊（削除/暗号化）する
- バックアップを取得することと、守り切ることは別である
- バックアップが残ってさえいれば、それを切り札として復旧を目指せる
- 「WORM (Write-Once-Read-Many)」技術を採用し、破壊＆改ざんがされないイミュータブルバックアップ戦略を維持運用することを推奨
- 可能であればセキュアデータバンカーとなる「Business Continuity OU」を用いて、クロスアカウントでバックアップを取得する
このようにすれば、バックアップが破壊されることはありません。仮に AWS アカウント自体が利用不可となっても、クロスアカウント戦略を行っていれば、クロスアカウント先からバックアップを取得できます。
ノーウェアランサムという脅威
しかし、「WORM (イミュータブルバックアップ) で破壊＆改ざんを防げれば、それでランサムウェアに勝利できるのか？」と問われると、残念ながら答えは No となってしまいます。
どうしてでしょうか？
重要なのは、昨今増加傾向にある「ノーウェアランサム」という攻撃手法です*1。
ノーウェアランサムとは、データの暗号化を行わず、「データを盗み出し（盗難 Exfiltration）、その後に"公開するぞ"と脅迫する」ことに特化した攻撃です*2。
攻撃と防御はいたちごっこです。攻撃者は「イミュータブルバックアップを破壊することはできない」と既に学んでおり、数年も前から「次の手」を考え、実行に移してきています。
イミュータブルバックアップは、破壊はできないものの「Read-Many」であるため、参照は可能です。よって、データを持ち出すことはできてしまいます。そしてこれが、データ盗難につながります。
96% がデータ窃取を伴う攻撃という情報も
サイバーセキュリティ企業 BlackFog の「The State of Ransomware Report Q3 2025」によると、2025年第3四半期のランサムウェア攻撃において、実に 96% がデータ窃取を伴うものであったと報告されています。
Data theft remains the dominant tactic used by attackers, with 96% of all disclosed cases involving data exfiltration, marking the highest level recorded to date.
[和訳]
データ窃盗は依然として攻撃者が使用する主な戦術であり、公開された全ケースの 96% がデータ窃盗に関係しており、これはこれまでで最高レベルです。
https://www.blackfog.com/blackfog-report-reveals-36-increase-in-q3-ransomware-attacks-yoy/
攻撃者にとって、データの暗号化はもはや必須の攻撃ではありません。
イミュータブルバックアップでバックアップが強固に守られており「データの復旧」が可能であったとしても、「機密情報の漏洩」という脅しにより、企業は身代金の支払いを余儀なくされるためです。
したがって、イミュータブルバックアップに ＋α として、「データの境界（Data Perimeter）」を構築し、信頼されていない外部からのアクセスをリソース側で遮断する対策が合わせて必要になります。
ランサムウェア攻撃の比較
二重恐喝 (暴露型) も含めて整理すると、以下の表になります。
| 攻撃手法 | データ暗号化 | データ窃取 | 主な脅迫内容 | AWS での対策 |
|---|---|---|---|---|
| 従来型 | あり | なし | 「データを復号したければ払え」 | イミュータブルバックアップ |
| 二重恐喝 (暴露型) | あり | あり | 「復号」＋「暴露されたくなければ払え」 | イミュータブルバックアップ + データ境界 |
| ノーウェアランサム | なし | あり | 「暴露されたくなければ払え」のみ | データ境界 |
さて、前置きが長くなりましたが、本ブログはその「＋α」を AWS で考えるためのブログです。
なお本ブログも中・上級者向けの内容になっている点についてはご容赦ください*3。AWS Organizations のポリシーに関しては以下のブログも合わせてご参考ください。
AWS ホワイトペーパーの紹介
AWS Whitepaper として「Building a Data Perimeter on AWS」が公開されています。
これは2021年7月に公開されたホワイトペーパーで、最終更新日付は現在2024年11月13日となっています。
最後の更新では resource control policies (RCPs) に関するアップデートが行われています。合わせて是非ご覧ください。
ノーウェアランサム対策としての Data Perimeter
ではここから、実際にノーウェアランサム対策の「データ境界」として役立つ AWS の機能をご紹介します。基本的には上記の AWS ホワイトペーパーを参考にご紹介します。
そもそも「データ境界」とは何か？
データ境界（Data Perimeter）とは、AWS 環境上のデータを取り囲む「論理的なガードレールの集合体」です。
単にネットワークを閉じるのではなく、アクセスする「①主体（Identity）」、アクセスされる「②場所（Resource）」、そして「③経路（Network）」の3要素すべてが「自組織の信頼できるもの」であるかを常に検証するという概念です。
これにより、外部からの侵入を防ぐだけでなく、内部不正や認証情報の悪用による「データの持ち出し」も予防することが可能です。
ネットワーク境界だけに頼らず、ID とリソースを含めた多層的な境界線を構築し、データを確実に自社の管理下に留めるためのアプローチです。
サマリー表
次の表は、必要な承認条件をサポートする境界目標を達成するために、各ポリシーがどのように使用されるかを示しています。先のホワイトペーパーにあるサマリー一覧表を、日本語版として作成しました。
| 認可条件 | 境界の目的 | 使用するポリシー | 主要な IAM 条件キー |
|---|---|---|---|
| Only trusted identities | 自社のリソースに対し、信頼されたアイデンティティのみがアクセス可能 | RCP | aws:PrincipalOrgID,aws:PrincipalIsAWSService,aws:SourceOrgID |
| 自社のネットワークから、信頼されたアイデンティティのみが許可 | VPC EP policies | aws:PrincipalOrgID,aws:PrincipalIsAWSService |
|
| Only trusted resources | 自社のアイデンティティが、信頼されたリソースにのみアクセス可能 | SCP | aws:ResourceOrgID |
| 自社のネットワークから、信頼されたリソースにのみアクセス可能 | VPC EP policies | aws:ResourceOrgID |
|
| Only expected networks | 自社のアイデンティティが、期待されたネットワークからのみリソースへアクセス可能 | SCP | aws:SourceIp,aws:SourceVpc,aws:ViaAWSService |
| 自社のリソースに対し、期待されたネットワークからのみアクセス可能 | RCP | aws:SourceIp,aws:SourceVpc,aws:ViaAWSService,aws:PrincipalIsAWSService |
これを見ながら読み進めると理解が深まると思います。
ちなみに IAM の「データ境界を使用してアクセス許可のガードレールを確立する」に、日本語化されたより詳細な「Global condition context keys」についての解説があるので、合わせて参考にしてください。
1. RCP: Resource Control Policies
まず、比較的新しい機能であり、データ境界の中核を担う Resource Control Policies (RCP) です*4。
先の表で「Only trusted identities」に RCP が記載されているように「アイデンティティ」ベースでのポリシーを提供します。
RCP は、AWS Organizations の組織内にあるリソース、特に S3 バケットや KMS キーなど「外部へのアクセス許可を記載できるポリシーを持つサービス」に対して、組織レベルで「最大の権限（ガードレール）」を適用できる機能です。
これまで、外部からのアクセスを遮断するためには、S3 バケットポリシーなどの「リソースベースポリシー」を個々のリソースごとに設定する必要がありました。しかし、リソースやアカウントの数が増えるほど、設定漏れのリスクは高まります。
RCP を利用することで、組織全体のポリシーとして「信頼された組織（自組織）外からのアクセスをまとめて拒否（Deny）する」ことが可能になります。これにより、リソースを組織で保護することができるようになります。
具体的には、RCP に aws:PrincipalOrgID や aws:SourceOrgID という条件を含めることで、組織外のアイデンティティからのアクセスを一律で遮断できます。
JSON の記述例は、先のホワイトペーパーにも記載がありますが、以下の AWS 公式ブログも参考になります。
上記ブログから設定の引用となりますが、以下は S3 バケットへのアクセスを、組織に属する ID と、組織に代わって動作する AWS サービスのみに制限する RCP の例です。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "EnforceOrgIdentities", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "*", "Condition": { "StringNotEqualsIfExists": { "aws:PrincipalOrgID": "<MY-ORG-ID>" }, "BoolIfExists": { "aws:PrincipalIsAWSService": "false" } } }, { "Sid": "EnforceConfusedDeputyProtection", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "*", "Condition": { "StringNotEqualsIfExists": { "aws:SourceOrgID": "<MY-ORG-ID>" }, "Null": { "aws:SourceAccount": "false" }, "Bool": { "aws:PrincipalIsAWSService": "true" } } } ] }
このような RCP を適切に運用することで、仮に個別のリソースポリシーで攻撃者により広い権限（Allow *）を与えられたとしても、組織のガードレールである RCP が優先され、外部からのデータアクセス（窃取）を防ぐことができます。
2. SCP: Service control policies
次に、組織での制限と言えばおなじみの存在 Service Control Policies (SCP) です。
RCP が「リソース」を守る盾であるのに対し、SCP は「アイデンティティ（ユーザーやロール）」の振る舞いを制限する役割を果たします。
ここでは少々混乱が起きるかもしれませんので、整理してみましょう。
- RCP は AWS リソースを守るために「組織内の信頼されたアイデンティティ以外を制限」します。「組織外からの意図しないアクセスを防ぐための盾」です
- SCP は組織内のユーザーやロールが操作可能な AWS サービスをコントロールすることにより「意図しない操作からリソースを保護」します。「組織内のアイデンティティの制限となる縛り（鎖）」です
ノーウェアランサム対策において SCP が果たす重要な役割は、「内部のユーザー（あるいは乗っ取られた権限であるロール）に、データを外部へ持ち出させない」ことです。
例えば、EC2 インスタンスが乗っ取られてしまった場合、その EC2 インスタンスにアタッチされた IAM ロール（インスタンスプロファイル）が利用されてしまいます。攻撃者は入手した認証情報の権限を使って、データを自分の所有する外部の AWS アカウント（S3 バケット等）にコピーしようと試みます。
これを防ぐために、SCP で aws:ResourceOrgID の制御が可能です。これを宣言することで、「自組織以外のリソース」への書き込みアクションを Deny することが可能になります。
これにより、社内の正規のユーザーやプログラムであっても、組織管理外の S3 バケットへのデータアップロードが不可能になります。
「イミュータブルバックアップによってデータは消せないが、持ち出される」というリスクに対し、SCP は「持ち出し操作そのものを禁止する」というアプローチで対抗します。
3. VPC endpoint policies
ホワイトペーパーに記載のある3つ目のサービスは、ネットワークの出入口を守る VPC endpoint policies です。
VPC エンドポイントは、VPC 内部から AWS サービスへプライベート接続するための機能ですが、ここにもポリシー（VPC エンドポイントポリシー）を適用できます。これを活用することで、ネットワーク経路におけるデータ境界を構築します。
ここでは、主に以下の2つの観点で制御を行います。
- 信頼されたアイデンティティのみ通す:
aws:PrincipalOrgIDを使い、自組織の IAM プリンシパル以外がこのエンドポイントを利用することを防ぐ - 信頼されたリソースへのみアクセスさせる:
aws:ResourceOrgIDを使い、このエンドポイント経由でアクセスできる先を「自組織のリソース」のみに限定する
特に2点目が重要です。仮に攻撃者がマルウェア等を使って VPC 内の EC2 からデータを外部へ送信しようとしても、VPC エンドポイントポリシーで「宛先が自組織のリソースではない」通信をブロックすることで、データの流出をネットワークレベルで阻止できます。
アクセスする「①主体（Identity）」、アクセスされる「②場所（Resource）」、そして「③経路（Network）」の3つの異なるレイヤーで「組織内であるかどうか」を検証することで、どこか一箇所に設定のミスや権限奪取があったとしてもデータを外に出させないというデータ境界が完成します。
4. AWS Backup Logically Air-gapped Vault
4つ目に特筆事項として、以前のランサムウェア対策ブログでもご紹介した AWS Backup Logically Air-gapped Vault です。
「論理的にエアギャップされたボールト」は、バックアップデータを本番環境から隔離して保護する機能ですが、データ窃取対策としても重要な意味を持ちます。
このボールトは、AWS Resource Access Manager (RAM) を使用した共有を厳格に制御できます。
通常、バックアップデータはクロスアカウントコピーなどで共有・複製が可能ですが、攻撃者はこの機能を悪用し、バックアップデータを自分のアカウントへ「共有」または「コピー」して持ち出そうとすることがあります。
Logically Air-gapped Vault では、以下のような対策が可能です。
- アカウント間の共有制限: 特定の信頼されたアカウント以外へのバックアップ共有を制限する
- コピーの制限: ボールト内のデータが、許可されていない外部アカウントへコピーされることを防ぐ
これにより、バックアップデータが丸ごと外部へ持ち出されるリスクを最小限に抑えることができます。
具体的なデータ境界の実装のために
RCP の例は以下の Github にまとめて紹介されています。
加えて、SCP の例は以下の Github にまとめて紹介されています。
ただし、「Data Perimeter Policy Examples」は以下にまとまっています。
まずは、これらのサンプルを実装のヒントとして参考にされると良いでしょう。
まとめ
本ブログでは、WORM を活用したイミュータブルバックアップに追加して、AWS におけるランサムウェア対策の「＋α」として考えたいデータ窃取を防ぐための「データ境界」について解説しました。
以下は簡単なまとめです。
- RCP (Resource Control Policies)
- 「リソースを守る盾」として機能します。S3 バケットなどのリソースに対し、組織外（信頼されていないアイデンティティ）からのアクセスを一律で拒否します。
- SCP (Service Control Policies)
- 「人の振る舞いを制限する縛り（鎖）」です。内部ユーザーや乗っ取られたロールが、組織管理外の外部リソースへデータを持ち出す（書き込む）操作そのものを禁止します。
- VPC Endpoint Policies
- 「ネットワークの検問」の役割を担います。VPC からの通信先を自組織のリソースのみに限定することで、ネットワーク経路を使ったデータの不正流出を阻止します。
- Air-gapped Vault
- 「最後の砦の隔離」を行います。バックアップデータの他アカウントへの共有やコピーを厳格に制限し、バックアップファイルごと外部へ持ち出されるリスクを最小化します。
ノーウェアランサムが台頭する現在では、これら AWS の機能を組み合わせた「データを外部へと持ち出させない」ための多層防御が求められています。
「イミュータブルバックアップで守っているから大丈夫」では終わらせず、自社の AWS 環境が「データの持ち出し」に対してどの程度耐性を持っているか、見直してみてはいかがでしょうか。
本ブログが、皆様の AWS 環境におけるセキュリティ向上のヒントになれば幸いです。
では、またお会いしましょう。
*1:なお「ノーウェアランサム」は警察庁による日本独自の造語だそうで、英語圏では Extortion-Only Attacks（恐喝特化型攻撃）等の用語が一般的です
*2:内部犯行や事故による漏洩（Leak）と区別し、外部からの窃取には Exfiltration が使われます。Exfiltration は「持ち出し」という手口を、Extortion は「恐喝」という目的を指す用語として使い分けられています
*3:特に技術的な内容では、AWS Organizations の機能を前提として話を進めます
*4:複数形を使うと少々読みにくいと思われますため、単数形で統一します
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
セキュリティサービス部所属。AWS資格全冠。2010年1月からAWSを業務利用してきています。主な表彰歴 2021-2022 AWS Ambassadors/2020-2025 Japan AWS Top Engineers/2020-2025 All Certifications Engineers。AWSのコスト削減やマルチアカウント管理と運用を得意としています。
