ある組織では、次のような対策をすでに講じていました。
- Off-siteにBackupを保管する
- Immutableとして保護する
- Backup管理用の認証情報を、通常の管理用認証情報と分離する
しかし、ある高い管理権限を持つ経路からは、Backupの削除や破棄のような重要な操作を、一人の権限だけで完結できる状態が残っていました。
担当者は、あらためて考えてみて、次のことに気づきました。
Backupのコピーや認証情報を分離するだけでなく、破壊的な操作そのものについて、一つの特権経路だけで完結しない仕組みが必要ではないか。
この章では、Ransomwareのような破壊的な侵入や、特権的な権限の悪用・侵害が、Backup / Recovery capability自体をどのように脅かし得るかについて見ていきます。
10.1 Backup自体が攻撃対象になる
Chapter 9では、管理権限そのものも保護対象になることを見ました。この章では、その特権的な権限が悪用・侵害された場合に、どこまでRecovery capabilityへ影響し得るかを考えます。
まず押さえておきたいのは、次の点です。
Backup infrastructureや、アクセス可能なBackupデータそのものは、破壊的なランサムウェアインシデントにおいて、それ自体が攻撃対象になり得ます。
Backupは復旧のための仕組みですが、そうであるからといって攻撃の対象から外れるわけではありません。攻撃者は、Recovery capabilityそのものを損なわせたり、無効化させたりしようとする場合があります。アクセス可能な状態にあるBackupデータや、それを支える基盤が、標的にされる可能性があります。
この章では、具体的な攻撃の手口やマルウェアの技術的な仕組みまでは扱いません。ここで押さえておきたいのは、「Backupがあるから安心」ではなく、「Backup自体も守るべき対象である」という視点です。
10.2 特権的な権限が及ぼす影響
Backup / Recovery capabilityにとって特に大きな意味を持つのが、特権的な権限です。
特権的な権限が、悪用されるにせよ侵害されるにせよ、Backup / Recovery capabilityに大きな影響を与える場合があります。
ここで一つ、注意しておきたいことがあります。この本で確認できた根拠の範囲では、「悪意のある内部関係者」「侵害された特権アカウント」「意図しない操作ミス」を、それぞれ厳密に区別して論じる記述は見当たりませんでした。したがって、この章ではこれらを細かく分類せず、「特権的な権限が、何らかの理由でBackup / Recoveryにとって危険な経路になり得る」という広い捉え方で扱います。
また、これは「すべての管理者が脅威である」という意味ではありません。多くの場合、管理者は正当に権限を行使しています。ここで考えたいのは、もしその特権的な経路が悪用・侵害された場合に、どこまでの影響が生じ得るか、という視点です。
10.3 破壊的な操作に追加の認可を設ける
一つの特権的な経路だけで、重要な操作が完結してしまう状態には、リスクがあります。
Backupの削除や破棄のような破壊的な操作に、一人の権限だけでは完結しない追加の認可を設けることができます。
これを実現する考え方として、次のようなものがあります。
- Separation of Duties(職務分離): 一つの役割・一人の人物・一つの経路に、破壊的な操作を完結できる権限を集中させないようにする考え方です。
- Dual Authorization(複数人承認): 一つの重要な操作について、複数の認可主体の承認を必要とする考え方です。
ここで、Dual Authorizationと混同しやすい概念があります。
MFA(多要素認証)は、一人の利用者が本人であることを確認するための認証強化です。Dual Authorizationは、一つの重要操作について複数の認可主体を必要とする考え方です。両者は別のものです。 MFAを設定しているからといって、それが独立した複数人承認の仕組みになるわけではありません。
米国国立標準技術研究所、NISTが公開しているセキュリティ管理策のカタログでは、組織が定めたBackup情報の削除・破棄に対して、Dual Authorizationを求める管理策が直接示されています。
例えばAzureでは、Chapter 7で触れたResource Guardの仕組みを用いるMulti-user authorization(MUA)により、重要な操作に対して追加の承認を求める構成が可能です。Chapter 9で触れたAWS Backupのmulti-party approvalも、この考え方に対応する実装例です。これらはあくまで特定製品におけるbounded implementation exampleであり、実装の詳細は製品によって異なります。
10.4 追加の承認にも限界がある
Separation of DutiesやDual Authorizationは有用ですが、万能ではありません。
Separation of DutiesやDual Authorizationは、一人の特権主体だけで破壊的操作を完結できる状態を減らすうえで役立ちます。しかし、必要な複数の認可主体がすべて侵害された場合や、それらが共謀した場合まで、完全に防げるとは限りません。
つまり、承認する人数を増やすことは、リスクを減らす有効な手段ですが、それ自体が絶対的な保証にはなりません。この本では、共謀(collusion)そのものを独立した脅威として詳しく扱うことはしませんが、「複数人承認があれば内部者リスクは完全に解決する」と考えるのは正しくない、という点は押さえておく必要があります。
10.5 監査証跡自体も保護する
破壊的な操作が行われたかどうか、誰が何を行ったかを確認するためには、監査証跡が重要になります。
監査情報や監査ツール自体も、不正なアクセス、改ざん、削除から保護される必要があります。
ここで注意したいのは、この保護を単純に「immutable audit」のような一つのラベルに還元しないことです。監査証跡の保護には、複数の異なる側面があります。誰がアクセスできるか、誰が内容を変更できるか、誰が削除できるか、これらはそれぞれ別に確認する必要がある事項です。
具体的にどのイベントをログすべきか、ログをどのように保管・分析すべきかという詳細な設計については、この章では扱いません。
10.6 人事・アカウントライフサイクルも関係する
技術的な保護だけでは、特権的なアクセスに関するすべてのリスクに対応できるわけではありません。
例えば、担当者が異動したり組織を離れたりする際に、その人物が持っていたアクセス権限やアカウントが適切に取り消されなければ、それ自体がリスクになります。
人事異動や離職に伴うアカウント管理は、Backupのimmutabilityや複数人承認だけでは対処できないリスクに対応する、別の統制です。
ここでの人事的な統制と、Backupの技術的な保護(immutabilityやDual Authorization)との関係は、この本独自の整理であり、単一の公式な分類として示されているわけではありません。組織的な人事セキュリティの体系そのものは、この章では扱いません。
10.7 Emergency Accessにも独自のリスクがある
最後に、もう一つ考えておきたい状況があります。
通常の管理経路が使えなくなる場合も想定しておく必要があります。例えば、identityの仕組み自体に障害が起きたり、信頼できない状態になったりすると、普段使っている管理経路そのものが利用できなくなることがあります。
こうした状況に備えて、通常とは別の経路(out-of-band)や、緊急時専用のRecovery Accessを用意しておくことで、recoverabilityを維持できる場合があります。
ただし、ここで注意が必要です。このEmergency Access自体が、強力な特権を持つ仕組みになるため、独自の期限管理と、独立した統制が必要になります。 普段は使わないからといって、無防備なまま放置してよいものではありません。
通常のidentityが使えない状態から、具体的にどのようにRecoveryを開始するかという設計については、この章では扱いません。この点は、後の章で改めて扱います。
10.8 まとめ
この章では、Ransomwareのような破壊的な侵入や、特権的な権限の悪用・侵害が、Backup / Recovery capability自体をどのように脅かし得るかを整理しました。
重要なのは、次の点です。
- Backup infrastructureとアクセス可能なBackupデータ自体が、破壊的なインシデントの攻撃対象になり得る。
- 特権的な権限は、悪用されるにせよ侵害されるにせよ、Backup / Recovery capabilityに大きな影響を与え得る。
- Separation of DutiesやDual Authorizationにより、一つの経路だけで破壊的操作を完結できない仕組みを作れる。MFAとDual Authorizationは別の概念である。
- Separation of Duties/Dual Authorizationも、複数の認可主体すべての侵害や共謀までは完全には防げない。
- 監査証跡自体も、単一のラベルに還元せず、複数の側面から保護する必要がある。
- 人事・アカウントライフサイクル管理も、技術的な保護だけでは対処できないリスクに対応する。
- Emergency Accessはrecoverabilityを助ける一方、それ自体が独自の統制を必要とする強力な特権である。
この章で確認する代表的な観点
ここまでの内容を、簡単な表として整理します。
| 観点 | どのようなリスクを減らすか | 何を確認するか | それだけでは保証されないこと |
|---|---|---|---|
| Separation of Duties | 一つの役割・経路への権限集中 | 破壊的操作を一人で完結できないか | 複数主体すべての侵害や共謀までは防げない |
| Dual Authorization | 単独承認による破壊的操作の実行 | 重要操作に複数の認可主体が必要か | 必要な複数の認可主体すべての侵害や共謀まで防ぐとは限らない |
| Audit Protection | 操作の追跡不能化 | アクセス・改ざん・削除それぞれへの保護があるか | 単一の「immutable audit」ラベルでは不十分な場合がある |
| Account Lifecycle | 不要になった権限の残存 | 異動・離職時にアクセス権限が適切に取り消されるか | 技術的なBackup保護だけでは対処できない |
| Emergency Access | 通常経路が使えない場合の復旧不能化 | Emergency Access自体に期限管理・独立統制があるか | 用意しただけでは安全とは言えない |
この表は、この章で扱う代表的な観点を整理したものであり、業界標準の固定的な分類ではありません。
次の章では、Restoreできたバックアップが、本当に信頼できる復旧点かどうかをどう判断するかについて見ていきます。
Chapter 10を読み終えた時点で考えてみてください
自分が担当しているシステムについて、次の質問に答えられるでしょうか。
- なぜBackup自体がRansomwareや破壊的侵入の攻撃対象になり得るのでしょうか。
- MFAとDual Authorizationの違いを説明できますか。
- Separation of DutiesやDual Authorizationだけで内部者リスクを完全に解決できないのはなぜでしょうか。
- 監査証跡自体も保護対象になるのはなぜでしょうか。
- Emergency AccessがRecoveryを助ける一方で、独自の統制を必要とするのはなぜでしょうか。
すべて答えられなくても問題ありません。
むしろ、答えに詰まった点があれば、それがこの章で確認しておくべきポイントです。