【2026年版】3つの防衛線でシステムを守り抜く！実践的なAWSでランサムウェア対策

はじめに

2026年現在、ランサムウェアは多くの企業の関心事となっています。
AWS は、多くの企業のクラウドインフラストラクチャとして多く利用されています。

AWS では、どのような方法でランサムウェア対策ができるのでしょうか？
本記事では、AWS の機能を活用したランサムウェア対策を、「防御・検知・回復」の3つのフェーズに分け、皆さんが自分の環境に適用できるレベルまで具体的に解説します。

ランサムウェアに対してクラウド全体でどのように備えていくかという上位レイヤー向けの提案記事については、別途公開される しろうささんの『【2026年最新】ランサムウェア対策に対する提言』をご確認ください。

1. 【防御】初期侵入を遮断する水際対策と権限の閉じ込め

初期の侵入フェーズにおいて、攻撃者が狙うのは GitHub のリポジトリや開発者の端末に残存する「静的なアクセスキー」です。AWS では、長期的なアクセスキーを廃止して、一時的に管理されたアクセスキーの利用を推奨しています。

SCPによるガードレールとアクセスキー発行禁止の仕組み

2026年のベストプラクティスにおいて、「アクセスキーのローテーション」は、もはや過去の対策です。長期アクセスキーそのものを廃止し、セッションベースの短い有効期限のクレデンシャルに移行することが重要です。
しかし、単に「使わないでください」と周知するだけでは不十分です。AWS Organizations の SCP（サービスコントロールポリシー） を使い、物理的にアクセスキーを作成できない環境（ガードレール）を構築します。

攻撃者の動き:

長期アクセスキーを奪取し、自由にIAMユーザーやロールを作成・変更して環境を乗っ取ろうとします。

【対策】

1. 境界ポリシー（Permission Boundary）の作成: 「アクセスキーの作成（iam:CreateAccessKey）」を明示的に拒否するポリシー（例：CoreSecurityBoundary）をあらかじめ作成しておきます。
2. SCPによる強制: エンジニアが新しいIAMロールやユーザーを作成する際、必ず上記の境界ポリシーをアタッチしなければならないように制限します。

以下のポリシーを適用することで、セキュリティ基準を満たさないIAMエンティティの作成を拒否し、結果として組織内での勝手なアクセスキー発行を封じ込めます。

実装するポリシー：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EnforceSecurityBoundaryOnIAMCreation",
            "Effect": "Deny",
            "Action": [
                "iam:CreateUser",
                "iam:CreateRole",
                "iam:PutUserPermissionsBoundary",
                "iam:PutRolePermissionsBoundary"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "iam:PermissionsBoundary": "arn:aws:iam::${aws:PrincipalAccount}:policy/CoreSecurityBoundary"
                }
            }
        },
        {
            "Sid": "PreventBoundaryDeletion",
            "Effect": "Deny",
            "Action": [
                "iam:DeleteUserPermissionsBoundary",
                "iam:DeleteRolePermissionsBoundary"
            ],
            "Resource": "*"
        }
    ]
}

このSCP単体でアクセスキーが消えるわけではなく、事前に CoreSecurityBoundary ポリシー内に、以下の記述を含めておくことが条件です。

• iam:CreateAccessKey を Deny する設定
• その他のセキュリティ禁止事項

これにより、開発者が作業用に権限の強いロールを作ろうとした際、必ずアクセスキー作成不可という制約がセットで付与されることになり、長期クレデンシャルが生まれる余地を無くすことができます。

ABAC (属性ベースアクセス制御) で横展開を防ぐ

初期侵入に成功した攻撃者が次に行うのは、奪ったクレデンシャルを使って権限の範囲を広げる ラテラルムーブメント です。この動きを止めることが重要です。

攻撃者の動き:

窃取したユーザーのクレデンシャルで、アクセス権があるかに関わらず、組織内の他のリソース（S3バケット、EC2など）へのアクセスを試みます。

【対策】

ABAC を導入し、IAM側とリソース側で付与されたタグが一致しない限り、操作を許可しません。これにより、権限をプロジェクト単位で論理的に「閉じ込める」ことが可能です。

​​タグの紐付け手順

1. IAM (アイデンティティ側) へのタグ付与:
   IdP連携時、ユーザーの属性（例: 部門名 Project: A-Project）を セッションタグ としてAWSに渡すように設定します。
2. AWSリソース側へのタグ付与:
   S3バケットやEC2インスタンスなど、保護対象の全てのリソースに同じキー（例: Project）でタグを付与します。
3. IAMポリシー (許可セット) の設定:
   Identity Centerで利用者に割り当てる許可セット（セッションに引き継がれるポリシー）に、以下の条件を追加します。

実装するポリシー：

<br />{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:::*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/Project": "${aws:PrincipalTag/Project}"
                }
            }
        }
    ]
}

このポリシーは、リソースタグ (aws:ResourceTag/Project) と、操作を行うプリンシパル（ユーザー/ロール）のタグ (aws:PrincipalTag/Project) が完全に一致しない限り、S3操作を許可しません。攻撃者がクレデンシャルを窃取しても、タグが異なるリソースには一切手出しできなくなります。

※実装前の重要事項

このポリシーは、IAM Identity Center（旧AWS SSO）で「属性ベースのアクセス制御」を有効にし、かつIdP側から適切に属性が渡されている場合に動作します。また有効に機能させるために、ポリシーの設定だけでなく保護対象となる全ての S3 バケットや EC2 インスタンス等に対して、正確にタグ（Projectタグ等）が付与されていることが条件となります。
タグ付けに漏れがあると、正規の利用者であってもアクセスできなくなるため、導入前のリソース棚卸しが重要です。

SCP による証跡の転送停止を阻止

攻撃者の証拠隠滅の動きをSCP (サービスコントロールポリシー)を使用して阻止する。

攻撃者の動き:

攻撃者は、管理者権限を奪取後に証拠隠滅のためにCloudTrailのログ記録を停止したり、ログ専用アカウントへの転送設定を削除しようとします。

【対策】

AWS Organizationsの SCP を使用し、CloudTrailの停止や設定変更を組織全体で拒否します。

実装するポリシー：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectCloudTrailSettings",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:DeleteTrail",
        "cloudtrail:StopLogging",
        "cloudtrail:UpdateTrail"
      ],
      "Resource": "*"
    }
  ]
}

このSCPを全メンバーアカウントに適用することで、本番アカウントが乗っ取られても、ログの転送を止める権限を攻撃者から物理的に剥奪できます。

ログは安全地帯であるログ専用アカウント（Log Archive）へ転送され続けます。

2. 【検知】ふるまいから見抜く「正規権限を悪用した侵攻」

近年のランサムウェア攻撃は、マルウェアを送り込むだけでなく、窃取した正規の権限を悪用し、AWSの標準機能を介してデータを破壊する傾向にあります。ここでは、AIによる不審な振る舞いの検知と、その後の自動的な封じ込め（レスポンス）に踏み込みます。

GuardDuty \× Lambdaによる自動封じ込め( Auto-Remediation )

GuardDutyが異常を検知した際、Lambdaで対象の権限を即座に無効化するフローを組むことが攻撃に有効です。

攻撃者の動き:

侵入に成功後、S3バケットへの大量アクセスや、普段と異なるリージョンからの不審なAPIコールといった「不審なふるまい」を行います。

【対策】

Amazon GuardDuty がAI・機械学習で不審な振る舞い（Finding）を検知した際、Amazon EventBridge と AWS Lambda を連携させ、対象の権限を即座に無効化する自動封じ込めを実装します。

Lambdaコードのロジック
1. トリガー: EventBridgeがGuardDutyのHigh Severity（重大度7.0以上）のFindingを検知した際にLambdaを起動。
2. ターゲット特定: Findingの detail.user.name から、侵害されたIAMユーザー/ロール名を特定。
3. Denyポリシーの作成・アタッチ: 以下の内容を持つIAMポリシーを動的に作成し、特定されたユーザー/ロールに強制的にアタッチします。
4. aws:TokenIssueTime を使って、検知時刻以前に発行された全トークンを物理的に「無効」化します。

Denyポリシーの例 (Policy Name: Deny-All-On-Breach)

// IAMロールにアタッチする強制失効ポリシーの例
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "DateLessThan": {
         　　　　　　 //ポリシー内の 2026-02-12T21:00:00Z の部分は、GuardDutyのFindingをトリガーにLambdaが起動した実行時刻（侵害検知時刻）を動的に設定する必要がある
                    "aws:TokenIssueTime": "2026-02-12T21:00:00Z" 
                }
            }
        }
    ]
}

このDenyポリシーをアタッチすることで、たとえユーザー/ロールがもともと持っていたAllowポリシーよりも優先度の高いDenyが適用され、そのセッションは即座に無力化されます。また検知以前に発行された全トークンを無効化し、攻撃者の手元の鍵はただのガラクタに変わります。

※導入時の注意点（False Positiveリスク）

自動遮断は強力ですが、正規のバッチ処理やデプロイ作業を「攻撃」と誤検知（False Positive）し、システムを停止させるリスクがあります。

推奨運用:

最初は「検知時は管理者のチャットツール（Slack等）へ即時通知する」フェーズから開始し、検知精度のチューニングを十分に行いましょう。
自動遮断を適用するのは、重要度 (Severity) が極めて高い（8.0以上など）特定の脅威タイプに限定するなど、慎重な検討が必要です。

Amazon Inspectorによるサプレッションルールでノイズを消す

攻撃者の動き:

過去に構築した検証用サーバのパッチ適用漏れや、塩漬けになったコンテナイメージといった「バックドア」となり得る脆弱性を侵入経路とします。

【対策】

Amazon Inspector を有効化し、脆弱性管理を自動化します。特に重要なのは、運用負荷を減らすために「ノイズを消す」ことです。

実務的なフィルタリング条件（サプレッションルール）

Inspectorを導入すると、数千件の警告が発生しがちです。修正不要なものを自動で抑制（サプレス）するための実務的なフィルタ条件は以下の通りです。

設定手順：

Amazon Inspectorの「結果 (Findings)」画面を開く。

1. フィルターバーで上記条件を入力し、対象を絞り込む。
2. 絞り込んだ状態で「抑制ルールを作成 (Create suppression rule)」をクリックし、アクションとして「抑制 (Suppress)」を選択。

重要なアラートがノイズに埋もれるのを防ぎ、管理者が今すぐ対処すべき本当にクリティカルな脆弱性に集中できる環境を構築します。

3.【回復】攻撃者に「消せない」バックアップの作成と復旧

ランサムウェア攻撃における最悪のシナリオは、『データの暗号化後、すべてのバックアップを削除され、身代金を要求されること』です。確実なバックアップがあれば、攻撃者の脅迫に屈する必要はありません。

AWS Backup Vault Lockによる「不変性（WORM）」の強制

攻撃者が AdministratorAccess を奪取した場合、彼らが最初に行うのはバックアップの削除です。

攻撃者の動き:

ルートユーザーと同等な管理者権限 (AdministratorAccess) を奪取後、最も最初に行うのはバックアップデータが保存されているS3バケットやAWS Backup Vaultの削除です。

【対策】

AWS Backup Vault Lock の コンプライアンスモード を適用し、バックアップボルト（保管庫）に WORM（Write Once Read Many）設定を強制します。これにより、ルートユーザーであっても削除・変更ができない強力な保護層を構築します。

設定ミスの高コストのリスクと「冷却期間」の運用案

aws backup put-backup-vault-lock-configuration \
    --backup-vault-name MyCriticalVault \
    --min-retention-days 30 \
    --changeable-for-days 3

min-retention-days` (最小保持期間) を誤って長く設定しすぎると、不要になったバックアップであっても指定期間（例では30日）は誰にも削除できなくなり、予期せぬストレージコストが永久に発生し続けるリスクがあります。

安全な導入のための「冷却期間」運用案:

1. --changeable-for-days に 3日 など短い期間を設定する（= 冷却期間）。
2. この冷却期間中に、バックアップジョブが正常に動作し、保持期間設定 (--min-retention-days) に問題がないかを徹底的に検証する。
3. 冷却期間が過ぎると、Vault Lock設定自体も削除・変更できなくなります。本番環境への適用前に必ず小規模な設定で検証してください。

クロスアカウントバックアップとKMSによる論理的な隔離

攻撃者の動き:

単一のAWSアカウントが完全に侵害された場合、Vault Lockを適用していても、そのアカウント内のリソース全てに攻撃者がアクセス不可状況を及ぼします。

【対策】

AWS Organizationsを活用し、バックアップ専用の隔離アカウント（隔離環境、エアギャップ）を作成します。

• 本番アカウントから隔離アカウントへバックアップを自動コピーします。
• 最も重要なのは、コピー先の隔離アカウント側では、本番アカウントのエンジニアでもアクセスできない厳格な権限管理を行うことです。

KMSキーポリシーによるデータ保護：

ランサムウェアがバックアップを暗号化解除できないようにするため、KMS（暗号化鍵）もコピー先の隔離アカウント側の鍵で再暗号化するように設計します。

隔離アカウント側のKMSキーポリシーの例：

以下のポリシーにより、本番アカウント (Source Account ID) からの暗号化操作のみを許可し、複合化 (Decrypt) は隔離アカウント内の特定の管理者ロール (Isolated Admin Role) のみに制限します。

{
    "Version": "2012-10-17",
    "Statement": [
        // 許可1: 本番アカウントからのデータの暗号化（バックアップの書き込み）のみ許可
        {
            "Sid": "AllowEncryptFromSourceAccount",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<Source Account ID>:root" // 本番アカウントのARN
            },
            "Action": "kms:Encrypt",
            "Resource": "*"
        },
        // 許可2: 復旧時の複合化は、隔離アカウント内の特定の管理者ロールのみに制限
        {
            "Sid": "AllowDecryptForIsolatedAdmin",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<Target Account ID>:role/IsolatedAdminRole" 
            },
            "Action": "kms:Decrypt",
            "Resource": "*"
        }
    ]
}

攻撃者が本番アカウントを乗っ取っても、その権限で隔離アカウントのKMSキーを使ってバックアップデータを複合化（読み取り）することは不可能になります。これにより、バックアップのデータの中身が守られます。

新規でクリーンな環境へのリストア（復旧）

攻撃者の動き:

バックアップが「消されなかった」としても、元の汚染されたAWSアカウントにそのまま書き戻すのは危険です。なぜなら攻撃者のバックドアが残っている可能性があるからです。

【対策】

復旧は、新規でクリーンなAWSアカウントに対して行います。ここで、IaC（Terraform/CloudFormation）を利用しネットワークやサーバー群を新規に立ち上げ、データの復旧を試みます。

1. インフラの再構築：IaCを用いて、ネットワーク（VPC）やサーバー群を数分で新品の状態で立ち上げます。
2. クロスアカウント・リストアの実行：隔離アカウントに保管されたバックアップから、新規アカウントへデータを復元（リストア）します。
3. KMSによる復号：隔離アカウントの特定のロールのみが持つ kms:Decrypt 権限を使用して、データを復元します。

権限の逆転による復旧の実現：

リストア時には、本番アカウントではなく隔離アカウント側の復旧用ロールが主導権を握るように設定します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowRestoreToCleanAccount",
            "Effect": "Allow",
            "Action": [
                "backup:StartRestoreJob"
            ],
            "Resource": "arn:aws:backup:ap-northeast-1:<Target Account ID>:recovery-point:*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalAccount": "<Isolated Account ID>"
                }
            }
        }
    ]
}

対策フェーズと主要なサービス

まとめ

ランサムウェア攻撃は、依然としてサイバー脅威の主流であり、2026年もさらなる進化・高度化を遂げて流行することが予想されます。
ランサムウェアの対策は、攻撃のフェーズに合わせて複数の対抗手段を AWS 環境内に構築することが重要です。

本記事で紹介した設定 は、攻撃者にとって最も嫌がる障壁となります。これらは強力である反面、導入には慎重な検証期間（Cooling-off period）の設定が不可欠です。

この記事を読んだ今が、セキュリティ設定を見直す最良のタイミングです。まずは AWS マネジメントコンソールを開き、現在の設定が安全か確認してみてください。