Veritas Backup Exec vs. Veeam Backup & Replication の比較

両者はどちらもバックアップ市場のリーダー的な存在ですが、「生い立ち」と「得意分野」が明確に異なります。 一言で言うと、「物理環境・テープ重視なら Backup Exec」「仮想環境・スピード重視なら Veeam というのが今までの一般的な住み分けです。

次に、選定のポイントとなる主な違いを整理します。

1.比較サマリー表

機能・特徴Veritas Backup Exec (BE)Veeam Backup & Replication
得意な環境物理サーバー、ハイブリッド環境仮想環境 (VMware/Hyper-V/Nutanix)
生い立ち物理サーバー向けバックアップの老舗仮想化専用バックアップとして誕生
テープ装置非常に強い (LTOなどの管理が得意)対応しているが、BEほど多機能ではない
操作性 (UI)従来型の詳細設定型 (やや複雑)モダンで直感的 (シンプル)
復旧速度標準的 (インスタントリカバリも対応)高速 (Instant VM Recoveryが強力)
ライセンス容量課金、またはエージェント/ソケット単位VUL (ユニバーサルライセンス) / サブスクリプション
クラウド連携対応 (AWS/Azure/Google等)非常に強い (S3/Blobへの直接転送・不変性等)

2.それぞれの強みと弱み

物理サーバー時代からの長い歴史があり、「Windowsサーバーのバックアップといえばこれ」と言われるほどの定番ソフトでした。

Veritas Backup Exec

物理サーバー時代からの長い歴史があり、「Windowsサーバーのバックアップといえばこれ」と言われるほどの定番ソフトでした。

強み:

  • 物理環境とテープ運用の統合: 物理サーバーが多く、かつテープ(LTO等)での長期保管が必須要件である場合、テープドライブの詳細な制御や管理機能においてVeeamより一日の長があります。
  • きめ細かい設定: 除外設定やスケジュールなど、非常に細かい粒度で設定が可能です。
  • GRT (Granular Recovery Technology): Active DirectoryやExchangeなどのアプリケーションアイテム単位の復旧技術に定評があります(Veeamも現在は同等の機能を持っています)。

弱み:

  • 管理コンソールの重さ: UIがやや古く、設定項目が多岐にわたるため、初心者には学習コストが高い傾向があります。
  • 仮想化への対応: もちろん対応していますが、後付けで機能拡張してきた経緯があるため、Veeamほどの軽快さがないと感じる場合があります。

Veeam Backup & Replication

当初は「仮想環境のため」に設計されたソフトウェアです。エージェントレス(仮想マシンにソフトを入れない)でのバックアップをいち早く広めました。

強み:

  • 圧倒的な使いやすさ: “It just works”(設定すれば動く)という評判通り、UIがシンプルで直感的です。
  • Instant VM Recovery: バックアップファイルから直接仮想マシンを起動する技術が非常に強力で、数TBのサーバーでも数分で起動(RTO短縮)できます。
  • エージェントレス: 仮想環境であれば、個々のサーバーにソフトをインストールする手間がありません。
  • 物理・クラウドへの拡張: 現在は物理サーバー(Agent使用)やクラウド(AWS/Azure)への対応も非常に強化されています。

弱み:

  • テープ運用の柔軟性: テープへの書き込みは可能ですが、複雑なライブラリ管理や運用ルールに関しては、Backup Execの方が柔軟な場合があります。
  • 物理サーバー管理: 物理サーバーには個別に「Veeam Agent」を入れる必要があり、純粋な物理環境のみの場合、管理の手間はBackup Execと変わりません。

3.ライセンス体系の違い

Backup Exec:

  • 以前は「エディション(Bronze/Silver/Gold)」と「容量(TB単価)」または「ソケット数」の組み合わせが主流でした。
  • 物理サーバーが多い環境では、従来通りのライセンス体系がコストメリットを出すこともあります。

Veeam Backup & Replication

  • VUL (Veeam Universal License): ワークロード(VM、物理サーバー、クラウドインスタンス)を「1単位」としてカウントするサブスクリプション方式が主流です。
  • 環境が変わっても(物理から仮想へ移行しても)、ライセンスをそのまま移行できるポータビリティが魅力です。

結論:どちらを選ぶべきか?

Backup Exec が選ばれるケース:

  • 物理サーバーがメインの環境である。
  • テープバックアップの運用フローが確立されており、複雑なテープ管理が必要。
  • 既に長年 Backup Exec を使用しており、運用を変えたくない。

Veeam を選ぶべきケース

  • 仮想化環境 (VMware/Hyper-V/Nutanix) がメインである。
  • 復旧スピード (RTO) を最優先したい。
  • 将来的にクラウドへの移行やハイブリッドクラウド運用を考えている。
  • 管理の手間を減らし、シンプルな運用に切り替えたい。

現在のご利用環境(物理サーバーの台数、仮想マシンの台数、テープの有無など)により、コスト的・運用的の有利性が変わってきます。

Veritas Backup Execは現在は:

Veritas Backup Exec は、2026年1月現在、非常に大きな転換期を迎えています。

端的に言うと、「Veritas という会社は分割され、Backup Exec は『Arctera (アークテラ)』という新会社に移管」されました。

以前のように「VeritasのBackup Exec」ではなくなっている(またはその過渡期にある)というのが現在の正確な状況です。

以下に最新状況をまとめます。

1. 会社が変わった (Veritasの分割とArcteraの誕生)

2024年末から2025年にかけて、Veritas Technologies は2つの事業に分割・再編されました。

  • NetBackup (エンタープライズ向け事業):
    • 競合であった Cohesity (コヒシティ) と統合されました。
    • 大企業向けの製品群はこちらに吸収されています。
  • Backup Exec と InfoScale (その他の事業):
    • 「Arctera (アークテラ)」 という新しい独立した会社としてスピンオフ(分離)しました。
    • 現在、Backup Exec の開発・サポートはこの新会社 Arctera が行っています。

ユーザーへの影響: 今のところ製品名やサポート体制は維持されていますが、Webサイトや契約先、ブランドロゴなどが順次「Veritas」から「Arctera」へ切り替わっている段階です。今後の製品計画などは未定の様です。

タグ: ,

ExaGrid とWasabi Hot Strageのエアギャップ機能の比較

ExaGrid Wasabi Hot Cloud Storage(以下 Wasabi)は、どちらも「バックアップデータの保護」に強みを持っていますが、そのアプローチや「エアギャップ」の定義には大きな違いがあります。

結論から言うと、ExaGrid は物理・論理を組み合わせた「二層構造」による隔離を得意とし、Wasabi はクラウド上の「不変性(オブジェクトロック)」と「秘匿性」による論理的隔離を得意としています。

それぞれのエアギャップ(またはそれに相当する機能)の比較表

比較項目ExaGrid (Tiered Backup Storage)Wasabi Hot Cloud Storage
主な隔離手法階層型エアギャップ (Tiered Air Gap)オブジェクトロック & Covert Copy
アーキテクチャネットワーク接続層(LZ) + 非接続層(RT)全てクラウド(S3)接続。論理的に保護。
削除への対策Retention Time-Lock (削除遅延)不変性 (期間内の削除・変更不可)
管理者権限の保護2要素認証(2FA) + 二重権限設定マルチユーザ認証 (Covert Copy用)
物理的隔離同一筐体内だが、RT層は外部から不可視なし (パブリッククラウド)
主な用途オンプレミスの高速バックアップと保護オフサイトの長期保管・低コスト保護

1. ExaGrid のエアギャップ機能

ExaGrid は、バックアップ専用のストレージとして「二層構造」を採用することで、独自のエアギャップを実現しています。

  • 階層型エアギャップ (Tiered Air Gap): データを「ネットワークに面した層 (Landing Zone)」で受け取り、その後「ネットワークに接続されていない層 (Repository Tier)」に自動転送します。ハッカーがネットワーク経由で攻撃しても、後者の層には直接アクセスできません。
  • Retention Time-Lock (RTL): バックアップソフト等から削除命令が来ても、即座には削除せず、設定した期間(例:10日間)データを保持し続けます。これにより、バックアップ管理者のアカウントが乗っ取られて「全削除」されても、復旧が可能です。
  • 不変オブジェクト: リポジトリ層に保存されたデータは不変(イミュータブル)なオブジェクトとして管理され、改ざんが不可能な状態になります。

2. Wasabi のエアギャップ(相当)機能

Wasabi はクラウドストレージであるため、物理的な遮断ではなく、ソフトウェアとポリシーによる「論理的なエアギャップ」を提供しています。

  • マルチユーザ認証: Covert Copy や重要なポリシー変更には、複数の管理者の承認が必要な仕組みを導入しており、内部犯行や単一アカウントの流出に備えています。
  • S3 オブジェクトロック (Immutability): 一度書き込んだデータを、指定した期間(数日〜数年)「削除も変更もできない」状態にします。これは最も強力な防御策の一つです。
  • Covert Copy (2025年末発表の最新機能): バケットの「隠しコピー」を作成する新機能です。通常の管理画面やAPIからはコピーが存在すること自体が見えない(不可視)ため、たとえ管理アカウントが乗っ取られても、攻撃者はそのデータの存在に気づくことすらできません。

どちらを選択すべきか?

ExaGrid を選ぶべきケース:

  • バックアップ専用機器として、ネットワークから論理的に切り離された安全な階層を物理的に確保したい。
  • オンプレミス環境で、バックアップとリストアのスピード(即時復旧)を最優先したい。

Wasabi を選ぶべきケース:

新機能(Covert Copy)などで、データの存在自体を隠蔽する高度な秘匿性を重視したい。

  • オフサイト(遠隔地)へのバックアップを低コストで実現したい。
  • S3互換の柔軟性を活かしつつ、不変性(ロック)によってランサムウェアからデータを守りたい。

世界的にシェアの高い Veeam Backup & Replicationとの連携手順・構成

ExaGrid × Veeam

連携の仕組み: ExaGrid は Veeam の「Data Mover」をアプライアンス内に統合しています。

構成手順:

  • Veeam の管理画面から「Backup Repository」を追加。
  • 種類として「ExaGrid」を選択。
  • ExaGrid の IP アドレスと認証情報を入力。

メリット: プロトコルに NFS/SMB ではなく、高速な Veeam Accelerated Data Mover を使用するため、合成フルバックアップや起動(Instant VM Recovery)が非常に高速です。

Wasabi × Veeam

連携の仕組み: Veeam の「Scale-Out Backup Repository (SOBR)」機能を使用して、クラウドへデータを階層化(オフロード)します。

構成手順:

  • Wasabi 側で S3 バケットを作成し、「オブジェクトロック(不変性)」を有効化。
  • Veeam で「Object Storage Repository」として Wasabi を登録(S3 互換ストレージとして)。
  • ローカルリポジトリと Wasabi を組み合わせて SOBR を作成。

メリット: 「不変性」にチェックを入れるだけで、Veeam 側から Wasabi 上のデータをロックし、ランサムウェアから保護できます。

経費の考え方のポイント

Wasabi: 1TB あたりが非常に低価格でシンプルです。「予測可能なコスト」が最大の魅力ですが、データが数PB(ペタバイト)規模になると、自社所有の ExaGrid の方が安くなる分岐点が存在します。

ExaGrid: 重複排除率が非常に高いため(例 10:1 ~ 20:1)、実際に保存する物理容量を大幅に削減でき、長期的に見ると TB 単価が非常に安くなります。

まとめ:どちらの連携・コストモデルが適しているか

「リストア速度を重視し、長期的(5〜7年)に最も安く済ませたい」ExaGrid が適しています。強力な重複排除により、大容量データほどストレージ投資効率が良くなります。Veeam との連携も容易です。

「とにかく初期投資を抑え、月額でスモールスタートしたい」Wasabi が最適です。こちらもVeeam との連携も容易で、将来の容量増にも柔軟に対応できます。

タグ: , , ,

Microsoft 365のバックアップ自動化:M365バックアップコストを30%削減する方法

ここでは、下記の2つについての調査を紹介します。

●Microsoft 365バックアップソリューションが自動化を通じて組織にもたらす大幅なコスト削減と追加のデータ保護についての調査

●事例研究、報告書、および2023~2025年の評価によれば、自動化されたバックアップは効率性向上、復元時間の短縮、リソース最適化により30%のコスト削減を実現可能

Microsoft 365 バックアップ自動化の理解

Microsoft 365 バックアップ自動化とは、Exchange Online、SharePoint Online、OneDrive、Teams を含む Microsoft 365 コンポーネント全体で、重要なデータのバックアップコピーを自動的に、プログラム的に、かつ一元的に作成・管理する手段です。このような自動化システムは一般的に、1 日に複数回のバックアップを作成し、新規ユーザを自動的に検出し、Microsoft API のスロットリング制限を効率的に回避できるほど高度なインテリジェントな再試行ロジックを提供します。

Microsoft 共有責任モデル

Microsoft 365 に関する最大の誤解の一つは、クラウド上のデータは安全でありバックアップが不要だと信じることです。Microsoft の「共有責任モデル」では、インフラストラクチャの責任はMicrosoftが負いますが、データの復旧はお客様の責任となります。データが削除または破壊された場合、組織は3つの課題に直面します:データの損失、時間の損失、リソースの損失です。

Microsoft 365自体にはバージョン管理、保存ポリシー、ごみ箱といった標準機能が組み込まれていますが、明確にしておきましょう:これらは完全なバックアップソリューションではなく、そのようなものとして扱うべきではありません。Microsoft 365 管理者による削除後、ファイルおよびフォルダーの内容はごみ箱に移動し、90 日後に完全に削除され、その後は復元が不可能です。サードパーティ製バックアップはサイトおよびファイル/フォルダーレベルを保護し、迅速な復元を可能にし、誤削除によるデータ損失を防ぎます。

ネイティブの回復力 vs. 真のバックアップ自動化

Microsoft 365のネイティブ復旧ソリューションも進化を遂げ、基本的なデータ保護要件のカバー範囲をサポートするようになりました。しかし、これらは完全なバックアップ戦略とは言えません。一方、サードパーティの自動化ツールは、Microsoftの機能を超えるスケジュールされたバックアップ、細粒度の復旧、不変ストレージ、クロスプラットフォーム統合を提供します。

直接的なコスト削減メカニズム

自動化されたMicrosoft 365バックアップの導入による直接的なコスト削減効果は、以下の点で非常に顕著です:

インフラコスト無し

一方、自社管理型のバックアップツールでは、企業がインフラ費用(サーバー、ストレージ機器、ネットワーク機器)の全額を負担する必要があります。初期費用が高く、維持・アップグレードに伴い継続的なコストも増加します。クラウドベースのバックアップ自動化では、プロバイダーがサーバー、ストレージ、ネットワークのすべてを管理するため、この投資が完全に不要になります。

予測可能な価格設定

Climb Cloud Backup for Microsoft 365/Google Workspaceのような真の自動バックアップは、柔軟な価格プランでコスト削減を支援します。ユーザのライフサイクルを自動化するこのようなソリューションは、ライセンス費用の大幅な削減につながります。「新規ユーザを検出し、退職ユーザを自動アーカイブ」といった機能は、従業員の入社・離職時のユーザー管理を容易にします。この自動化された手法により、企業は非アクティブユーザのライセンスを停止でき、長期的に大幅な節約を実現します。

自動化されたレポートとアラート

予定されたレポートとアラートが自動的に実現されるため、ITチームが日常的な活動の監視や診断に費やす時間が大幅に削減されます。さらに、データ損失や規制不遵守といった高額な損失につながる問題を早期に特定する基盤としても機能します。手動監視の必要性が減ることで、企業は運用コストを最大50%削減でき、インシデントへの迅速な対応によりバックアップの信頼性と監査対応態勢の向上を実現します。

集中管理

単一のデータ保護プラットフォームによる集中管理は、監視、レポート作成、ポリシー適用を一つのユーザ・インターフェースに統合することで、MSPやその他の組織の運用コストを削減します。これによりワークフロー、トレーニング、ライセンス費用が削減され、人的ミスも回避されます。特にMSPは人員を増やさずに多くのクライアントを管理でき、SLA達成率を向上させ、管理コストを最大60%削減できます。

柔軟なライセンスポリシー

隠れた費用や長期契約を伴わない柔軟なライセンスにより、MSPなどは実際に使用した容量分のみを支払うことが可能です。アクティブユーザに対してのみ課金されるため、無駄やコスト超過を削減できます。このモデルにより、予測精度が向上し、顧客のセールスファネル通過が加速し、スケーリングが容易になります。長期契約に伴う財務的負担から解放されることで、組織は財務的な柔軟性を獲得し、多様なクライアントニーズに適合する、費用対効果に優れた明確なバックアップソリューションを提供できます。

間接的コスト削減メカニズム

人件費削減

IT要員コスト最大40%削減:システム更新の手動実行やバックアップ維持といった細かい作業に手間をかけることで、人件費の増加要因となる手動介入の必要性を排除し、コスト削減を実現します。

例:IT管理者3名が月30時間(時給50ドル)を手動更新・バックアップに費やす企業の場合、月額4,500ドル(年54,000ドル)を支払っています。これらのタスクを自動化することで人件費を40%削減し、年間21,600ドルを節約できます。

より迅速な復旧とダウンタイムの削減

旧式のソフトウェアは、システム障害やセキュリティ侵害の原因となり、生産性の低下による多額の損失につながる可能性があります。

同時に、自動化により、企業はユーザの生産性を損なうことなく、重要なアップデートを可能な限り迅速に適用することができます。

例:ガートナーの報告によれば、ITダウンタイムは企業に1分あたり平均5,600ドルの損失をもたらします。月に1時間のダウンタイムは年間33万6千ドルに相当します。ソフトウェア更新の自動化により50%の時間削減が可能となり、年間16万8千ドルから56万ドルのコスト削減が見込めます。

リスク軽減の価値

データ損失のコストは、復旧コストを上回ります。自動バックアップの経済的効果は、リスクを軽減する点で非常に大きいのです。

小規模なデータ損失事故(100ファイル未満)は組織に通常18,000ドルから35,000ドルのコストを発生させる

大規模なデータ損失事故(1億件以上のレコード)は最大500万ドルから1,560万ドルのコストを発生させる

侵害後の対応努力だけでも、2024年には120万ドルから135万ドルに増加している

セキュリティ対策とコンプライアンス遵守によるセキュリティ侵害コストの回避

古いセキュリティ更新プログラムは、企業をサイバー攻撃やコンプライアンス違反のリスクに晒します。セキュリティパッチの自動化により、データ攻撃や規制違反による罰則を回避できます。中小企業(SMB)における単一サイバー攻撃のコスト:120,000ドル(IBM)。自動セキュリティ更新により、ほぼ全ての侵害を防止可能で、6桁の損失を回避できます。インシデントの90%は予防可能です。

ストレージとバックアップの最適化

手動バックアップはストレージの過剰プロビジョニングを招き、コストを膨らませます。自動化されたクラウドベースのバックアップは増分保存を利用し、不要な支出を削減します。中規模企業がバックアップストレージに月額10,000ドルを支出している場合、自動化によりバックアップストレージを60%削減できます。年間節約額:72,000ドル。

人的ミスを減らす

ITポリシーコンプライアンスグループの最新データによると、データ損失インシデントの50%は人的ミスが唯一の要因です。

ガートナーの調査では、Microsoft 365を利用する組織にとって人的ミスが主要なリスク要因の一つと特定されています。

人的ミスの具体的な形態には以下が含まれます:

  • ファイル、メール、またはユーザアカウント全体の誤削除
  • 誤った受信者へのメール送信またはデータ共有
  • 適切なメールプロトコル(Bccなど)の使用不備
  • 機密情報の黒塗り処理不備

自動化は、保存ポリシー、バックアップ検証、障害アラート、迅速なデータ復旧オプションにより人的ミスを削減します。

Microsoft 365 バックアップ サービス vc サードパーティ・ソリューション

Microsoft のネイティブ バックアップ サービスは、2024 年より利用可能となり、支払い完了後に Microsoft 365 管理センターからアクセスできます。従量課金制で、保護対象コンテンツ 1GB あたり月額 0.15 ドルです。このサービスには Exchange Online、SharePoint、OneDrive が含まれ、サービス価格は保護対象コンテンツ(ユーザ・データおよび復元用に保持される削除済みデータやバージョン管理データ)の量に基づいて算出されます。

一方、サードパーティ製バックアップソリューションは長期的に見てはるかに低コストです。柔軟な価格設定(GB単位またはユーザ単位)、低コストなストレージプロバイダーの選択、ファイル単位の復元やポリシー駆動型自動化といった追加機能を提供します。これにより組織はバックアップ戦略を最大化し、運用コストを削減、ストレージ費用と比較して最大80%の節約を実現すると同時に、コンプライアンスと耐障害性を向上させることが可能です。

バックアップ自動化の新たな動向

Microsoft 365のバックアップ市場は激動しており、すでにいくつかの顕著な傾向が見られます。

ソフトウェア・アズ・ア・サービス(SaaS)提供モデルへの移行

「バックアップおよびリカバリ市場の規模が拡大するにつれ、より多くのベンダーがSaaS提供モデルへ移行すると考えられます」。この変化は、オンプレミス領域で巨大な存在感を示すバックアップベンダーがクラウドホスティング戦略を展開する事例(例:Climb Cloud Backup for Microsoft365 and Google Workspace)からも確認できる。これは企業がクラウドサービスへ移行し管理負担軽減を図る全体的な潮流にも合致する。SaaS提供モデルは高コストなオンプレミスインフラの必要性を排除し、保守費用を削減、総所有コスト(TCO)を低減する。

ゼロトラストアーキテクチャ:ゼロトラストアーキテクチャ統合

ゼロトラストアーキテクチャとは、たとえ企業ネットワーク内で動作している場合でも、デフォルトではいかなるデバイス、ユーザ、アプリケーションも信頼しないことを意味します。すべてが検証されなければなりません:あなたが誰であるか、どこからアクセスしているか、なぜシステムにアクセスするのか、そして具体的に何をしようとしているのか。これをバックアップシステムに適用すると、バックアップの作成から復元までのすべてのステップが厳密に監視・検証される環境が実現します。ゼロトラスト統合は、侵害リスクの低減、横方向攻撃の抑制、そして高額なデータ損失・ダウンタイム・コンプライアンス問題・ランサムウェア被害の影響軽減を実現します。

AIベースの自動化と異常検知

将来のバックアップソリューションは、ランサムウェアやその他の脅威となる可能性のある異常な動作を検知するため、より高度なAIを次々と追加していくでしょう。自動化されたサイバー復旧ソリューションへのこの傾向は、インシデント対応を加速させ、人的ミスを最小限に抑えます。AI搭載のバックアップシステムは、人間の監視の必要性を最小限に抑え、脅威の検知と対応を迅速化することで、人件費を削減します。

結論

自動化がMicrosoft 365のバックアップにおいて大幅なコスト削減をもたらすことは実証済みであり、報告されている節約額はコストの30%近くに達します。この節約効果は、インフラコストの削減、必要な人員の減少、復旧時間の短縮、ライセンスの効率的な活用、リスク低減など、様々な領域から生まれています。

さらにMicrosoft 365データは1日あたり20億件の新規ファイルが追加される指数関数的成長を続けており、組織はより高い効率性と自動化されたバックアップソリューションを必要とします。適切な自動バックアップを選択することで、IT部門とビジネスステークホルダー双方にとってのウィンウィンを実現できます。

タグ: , ,

高可用性(HA): アーキテクチャ、原則、および実用の使用例

ハードウェアは故障する。電源装置は焼損し、光ファイバーは切断され、ハードドライブは故障する。高可用性(HA)は、これらの物理的な障害からエンドユーザを保護します。

これは自動フェイルオーバーに焦点を当てたシステム設計です。障害発生時には、トラフィックが即座に健全なコンポーネントへ迂回し、インフラストラクチャの障害にもかかわらずビジネスプロセスを継続させます。停止と再起動を伴う災害復旧(DR)とは異なり、HAはアプリケーション層に対して障害を不可視化することを目指します。

高可用性アーキテクチャ

高可用性(HA)には完全な依存関係チェーンが必要です。単一のファイアウォールの後ろに配置された冗長アプリケーションクラスターは無意味です。高可用性アーキテクチャは2つの核心概念に依存します:

冗長性:システムの重要な部分にはすべて複数のコピーが存在します。これらのコピーは連携して動作するため、1つのコンポーネントが故障しても別のコンポーネントが既に利用可能です。これにより単一障害点を排除し、システムを中断なく稼働させ続けます。

自動フェイルオーバー:システムは障害を検知し、健全なコンポーネントへ自動的に切り替えます。このプロセスにはITスタッフの手動操作が不要です。結果として復旧が迅速に行われ、ユーザーは障害発生に気付かない場合もあります。

人間がボタンを押す必要がある場合、それは高可用性ではありません。それは災害復旧(Disaster Recovery)です。

図1:シンプルなHA構成

冗長性の階層

ストレージのHAがなければ、コンピューティング・クラスタリングは効果を発揮しません。データが単一のSAN上に存在し、そのSANが故障した場合、コンピューティングクラスタは実行すべきものが何もなくなります。このため、共有ストレージまたは同期ミラーリング(StarWind Virtual SANVMware vSANなど)が必須となります。同様に、ネットワークレベルではマルチパシングが必要です。単一のケーブルやスイッチの故障は、接続の切断ではなくパケットの損失に留まるべきです。

したがって、適切な冗長システム設計のためには、IT環境の複数レベルにわたり高可用性を実装しなければなりません:

コンピューティング層

このレベルでは、複数のサーバーをクラスタリングすることで高可用性を実現します。これらのサーバはワークロードを共有し、互いの健全性を監視します。1台のサーバが障害を起こした場合、ワークロードは自動的にクラスタ内の別のサーバーに移行され、アプリケーションの実行を継続させます。

ストレージ層

ここでは、ストレージノード間でデータを分散することで高可用性を実現します。これにより、1台のストレージデバイスまたはノードが故障してもデータへのアクセスが維持されます。アプリケーションはデータの可用性に依存するため、ストレージの高可用性は全体的なアーキテクチャにおいて重要な要素です。

ネットワーク層

ネットワーク層では、複数のネットワークパスを使用することで高可用性を実現します。これは冗長化されたスイッチ、ファイアウォール、ルーター、およびネットワークリンクによって行われます。あるネットワークパスが障害を起こした場合、トラフィックは自動的に別のパスにリダイレクトされ、接続の問題を防止します。

「9(ナイン)」のコスト。稼働時間対予算

可用性は「9(ナイン)」で測定され、1年間におけるシステムの稼働率(%)を表します。経営陣はしばしば「ファイブナイン」(99.999%)を要求しながら、それを達成するために必要な予算を実際に承認しません。

以下の数値は、可用性パーセンテージが1年間の実際のダウンタイムにどのように変換されるかを示しています:

「9(ナイン)」対ダウンタイム:

  • 99%(ツーナイン): 年間約3.6日のダウンタイム。重要度の低いバッチ処理には許容範囲。
  • 99.9%(スリーナインズ): 年間約8.7時間のダウンタイム。大半の中小企業インフラの標準。
  • 99.99%(フォーナインズ): 年間約52分のダウンタイム。中堅企業やエンタープライズ生産環境に必須。
  • 99.999%(ファイブナインズ): 年間約5分のダウンタイム。銀行、医療、通信業界に必須。

厳しい現実として、99.9%から99.99%への移行にはコストが指数関数的に増加することが多く、単純な冗長化(アクティブ/パッシブ)から「本格的な」アクティブ/アクティブクラスタや地理的に分散したサイトへの移行が必要となる。99.99%から99.999%への移行にも同様の原則が適用される——こうした環境には綿密な計画、多額の投資、そして全インフラ層における完全なフォールトトレランスが求められる。

「複雑性のパラドックス」

システム設計におけるよくある見落としは、複雑性による負荷を無視することです。自動負荷分散を備えた複数サイトにまたがる分散クラスタのような複雑な高可用性(HA)システムは、新たな障害モードをもたらします。

フェイルオーバー制御ロジックが誤動作すると、ハードウェアに問題がない場合でもサービス停止を引き起こす可能性があります。これはノード間の通信が断絶し、両ノードが同一データの所有権を主張することでデータ破損を招く「スプリットブレイン」シナリオで頻繁に発生します。

これを防止するため、堅牢なHAでは通常、ネットワーク分割時に審判役として機能する「監視者」またはクォーラム機構が必要となる。

StarWind Virtual SANのようなソリューションは、複数のハートビート戦略を提供することでこの複雑性を解決します。特定の保護策(別々の物理リンク経由のハートビートなど)を用いた「監視者不要」の2ノード構成で動作可能であり、あるいは追加の軽量クラスタインスタンスや単純なファイル共有を用いた従来の監視者実装を許可し、接続を仲裁します。これにより安全なクォーラムを維持するために必要なインフラストラクチャのフットプリントが大幅に削減されます。

HAは災害復旧ではない(バックアップでもない)

高可用性(HA)の冗長化をあらゆるレベルで実装しても、機能する(かつテスト済みの)バックアップ戦略は依然として必須です。これは、HAがインフラストラクチャ障害からの保護のみを提供し、ソフトウェアの破損、人的ミス、サイバー攻撃からの保護を保証しないためです。

HAはバックアップの代わりにはなりません。

  • HAはインフラ障害から保護します。RAIDアレイやサーバーの1台が故障しても、HAはデータ(仮想マシンやコンテナ)を稼働状態に維持します。
  • バックアップはデータ破損から保護します。重要なデータベーステーブルを削除した場合、HAシステムはその削除を即座にミラーに複製します。結果として、高可用性ながら破損したデータが存在する状態になります。

同様に、HAは災害復旧(DR)とも異なります。HAは単一拠点内のスイッチ故障やサーバ再起動といった日常的な問題に対処します。DRは洪水や長期停電といったサイト全体の災害に対する保険です。HAは自動的かつ即時(RTO≈0)に動作しますが、DRは手動で時間がかかる場合が多く(RTO>1時間)です。

実使用例

以下は高可用性(HA)インフラの代表的な活用事例です:

医療(EHR & PACS)

病院は電子健康記録(EHR)と画像アーカイブ通信システム(PACS)に依存しています。ストレージバックエンドの障害は患者履歴や画像へのアクセスを遮断し、安全性を脅かします。HAはホスト障害時にも臨床アプリケーションを稼働させ続け、スタッフがITトラブルシューティングではなく治療に集中できるようにします。

製造業(SCADA & IIoT)

工場では組立ライン管理に監視制御・データ収集システム(SCADA)を使用します。サーバーのクラッシュは生産を停止させ、ライン上の材料(例:化学処理)を廃棄せざるを得ない状況を生じさせます。HAクラスタは、粉塵の多い環境や高振動環境などにおいて、制御ソフトウェアがハードウェアの不具合を生き延びることを保証することで、この「バッチ廃棄」を防ぎます。

海事・海洋(切断されたエッジ環境)

船舶や石油掘削装置は接続環境が限られており、クラウドフェイルオーバーは不可能です。航海中にナビゲーションシステムが故障した場合、乗組員はバックアップをダウンロードできません。堅牢な2ノードクラスターは自己修復機能を提供し、船舶が港に到着するまで無期限に運用を維持します。

小売・ROBO(分散サイト)

小売チェーンは遠隔オフィス/支店(ROBO)拠点で「マイクロクラスター」を運用。現地のPOSサーバーが故障すると店舗は決済処理不能に。自動化された2ノードHAクラスターは即時自己修復を可能にし、緊急のIT現場対応を要せずレジレーンを維持します。

金融サービス(トランザクションの完全性)

銀行にとって稼働時間の確保は規制順守を意味します。データベース障害は業務を停止させ、失敗したトランザクションのバックログを生じさせ、高コストな手動調整を必要とします。規制違反罰金のコストは、HAインフラへの投資額をしばしば上回ります。

教育(VDI & LMS)

学校は仮想デスクトップインフラ(VDI)と学習管理システム(LMS)に依存しています。試験中のクラスター障害は数千人の学生に影響します。HAはアクティブセッションを保護し、物理ホスト障害による学生の切断や試験データの損失を防ぎます。

映像監視(VMS)

スタンドアロンのネットワークビデオレコーダー(NVR)は、映像管理ソフトウェア(VMS)にとって単一障害点となります。HAストレージは汎用サーバー間で録画データをミラーリングし、専用エンタープライズハードウェアのコストをかけずに継続的な監視を保証します。

結局のところ、アーキテクチャを理解することは戦いの半分に過ぎません。真の課題は実装にあります。従来、「HAレベル」の耐障害性を実現するには高価な専用SANアレイが必要でした。しかし現代のアプローチでは、耐障害性をハードウェア層からソフトウェア層へ移行させることで、標準的な汎用サーバー上で高可用性を構築することが可能となっています。

中堅中小企業および遠隔オフィス向けStarWindソリューション

StarWind Virtual SAN (VSAN) – エッジおよび中小企業環境向けに、StarWind VSANは高価な物理SANの必要性を排除します。2台のサーバー間でデータを同期的にミラーリングし、単一の共有ストレージプールとして提供します。重要な点として、2ノード構成における「スプリットブレイン」シナリオを効果的に処理し、1つのノードがダウンした場合でも、データ破損なくもう一方のノードが透過的に引き継ぐことを保証します。

結論

高可用性は、冗長化のコストとダウンタイムのコストのバランスを取ります。StarWindのような現代的なツールは、専用ハードウェアの必要性を排除することで実装を簡素化しますが、その原則は厳格です:単一障害点を排除し、復旧を自動化し、クラスタとバックアップを混同してはなりません。

タグ: , , ,

データ管理の未来を切り開くストレージシステムの6つの主要トレンド

デジタル世界はデータ爆発の真っ只中にある。予測によれば、世界のデータ量は2019年のわずか45ゼタバイトから、2025年末までに181ゼタバイトに達する見込みだ。この驚異的な成長は、人工知能(AI)、モノのインターネット(IoT)デバイスの普及、そしてリアルタイム分析への絶え間ない需要によって推進されている。組織にとっての課題は、単にこのデータを保存することではなく、効率的かつ持続可能で安全な方法で保存することにある。今後を見据えると、次世代ストレージシステムを形作るいくつかの主要なトレンドが浮上している。

トレンド1:AIとデータの絶え間ない成長

AIはもはやニッチな技術ではなく、データ生成と消費の主要な推進力となっている。機械学習モデル、生成AI、リアルタイム分析はいずれも、トレーニングと継続的な運用において膨大なデータセットに依存している。AIトレーニングデータセットの規模は指数関数的に拡大しており、トレーニングセットの中央値は2021年の420億データポイントから2023年には7,500億以上に急増し、今後も増加が見込まれる。この止まらない成長は、ストレージシステムに対し、容量とパフォーマンスの両面での前例のない負荷を課している。

この流れに対応するため、組織はAI専用に設計されたストレージアーキテクチャを採用しつつある。NVMe over Fabrics(NVMe-oF)のような技術は、超高速データ転送と低遅延を実現し、大規模データセットへの迅速なアクセスを必要とするAIワークロードにとって不可欠である。AIアプリケーション向けに最適化されたデータパスと高いIOPS(1秒あたりの入出力操作数)を提供する専用SSDも登場している。

一方で、大容量ハードディスクドライブ(HDD)は、AIワークロードの膨大なストレージ要件を支える上で依然として重要な役割を果たし、長期データ保持やアーカイブニーズに対して信頼性が高く、スケーラブルでコスト効率に優れたソリューションを提供している。AIが進化を続ける中、ストレージには大容量かつ高性能が求められ、将来のイノベーションが求める膨大なデータ需要を支えつつ、経済的・環境的効率性を維持することが必要となるでしょう。

トレンド2:サステナビリティ – データストレージにおける環境配慮の必要性

現代技術の環境への影響がますます議論されています。当然のことながら、人工知能(AI)、機械学習(ML)、モノのインターネット(IoT)は、処理時と保存時双方において、増え続けるデータ量を膨大なエネルギーで消費している。最新の推計によれば、データセンターは世界の電力消費量の約3%を占める。持続可能性が経営陣の最優先課題となる中、組織はエネルギー消費と環境負荷の両方を削減する方法を模索している。

これを実現する最も具体的な方法の一つが、大容量ストレージドライブへのアップグレードである。例えば、1エクサバイトのストレージを展開する場合、26TB ePMR HDDから32TB UltraSMR HDDに移行することで、ラック数を18.7%削減、HDD数を18.8%削減、冷却や電力使用効率を含む総消費電力を18.8%削減するなど、大幅な節約が可能となる。これらの改善により、総所有コスト(TCO)と運用コストが削減され、データセンターの環境負荷が直接的に低減される。

最新のハードディスクドライブ(HDD)は、テラバイトあたりの消費電力を抑えながら大容量化を実現する大きな進歩を遂げている。一方、SSDは初期費用は高いものの、特に高性能ワークロードにおいてライフサイクル全体で大幅な省エネルギー効果をもたらします。重複排除や圧縮といったデータ管理手法は、ストレージ需要をさらに削減し、エネルギーコストと冷却コストの両方を削減。

トレンド3:HDDの持続的な役割とハイブリッドソリューションの台頭

どう考えても、HDDは長期間にわたって存在し続けるでしょう。AI/ML、ビッグデータ分析、クラウドによって生成されるデータの量は、指数関数的な速度で増え続けており、そのすべてのデータを信頼性が高く、費用対効果の高い方法で保存する必要があります。特定のハイパフォーマンスアプリケーションではSSDが台頭しているものの、HDD技術の進歩により、これまで以上に大容量のストレージが実現され、大規模な導入には欠かせない存在となっている。

組織が大規模なストレージソリューションを導入する際に最も重要な考慮事項の一つは、TCOです。大容量HDDは、資本支出(CapEx)と運用支出(OpEx)の両方を考慮した場合、一貫して最も低い総所有コスト(TCO)を実現します。これには電力消費、保守、修理、ストレージデバイスの初期取得コストが含まれる。このコスト効率性により、組織は運用効率と収益性の両方を最大化でき、HDDはハイパースケールデータセンター、クラウドプロバイダー、膨大な非構造化データを管理する企業にとって、現在および将来にわたるデータストレージの基盤となっている。

ヘリウム充填ドライブや記録密度の向上といった近年の技術革新により、HDDの性能と効率はさらに向上し、手頃な価格で拡張性のあるストレージの定番ソリューションとしての地位を確固たるものにしています。こうした利点から、HDDが現代のストレージアーキテクチャにおいて重要な構成要素であり続け、データ主導の未来においても中心的な役割を果たし続ける理由は明らか。

トレンド4:中東におけるデータセンターの急成長と拡張可能なインフラの必要性

中東では、デジタル変革を加速させる野心的な政府計画に後押しされ、データセンター投資が急増している。アリズトン社の最新レポートによると、同地域のデータセンター市場は2023年から2029年にかけて年平均成長率(CAGR)9%超で拡大が見込まれており、サウジアラビアの「サウジ・ビジョン2030」やアラブ首長国連邦(UAE)の「国家デジタル変革プログラム」といったイニシアチブが牽引役となっている。これらのプロジェクトは、堅牢でスケーラブルかつ安全なストレージソリューションへの需要を加速させている。ウェスタンデジタルなどの業界リーダーは、先進的なストレージ技術と専門知識を提供することで、同地域のデジタル野望を支え、この変革に積極的に貢献している。

トレンド5:データ主権:サーバーを物理的に抱きしめたいという願望

アラブ首長国連邦(UAE)は、2023年国家クラウドセキュリティ政策を基盤に、クラウド、データ、AI分野における地域リーダーへと成長しました。この政策は明確なセキュリティ基準を設定し、ローカルクラウドインフラを優先することで、データ主権を最重要課題としています。多くの組織にとって、データがどこに存在し、国内法によって保護されているかを正確に把握したいという「サーバーを物理的に抱きしめたい」という願望が現実のものとなっています。

規制順守を超えて、ローカルデータストレージはゼロトラストセキュリティを実現し、生成AIやIoTなどの高度なワークロードに必要な低遅延を提供。ローカルに保存されたデータへの即時アクセスを保証することで、組織はモデルトレーニングとリアルタイム分析を加速できると同時に、パフォーマンスとリソース利用率の両方を最適化する分散型ストレージアーキテクチャの柔軟性も享受できる。より多くの国が同様の方針を採用するにつれ、データ主権はストレージ戦略における決定的要因であり続けるだろう。

トレンド6:ソフトウェア定義型かつインテリジェントなストレージ:次なるフロンティア

組織がハイブリッドおよびマルチクラウド戦略を採用するにつれ、ソフトウェア定義型ストレージ(SDS)への移行が加速しています。SDSはデータ管理を物理ハードウェアから切り離し、ITチームにストレージリソースの展開、拡張、最適化をかつてない俊敏性で実行する柔軟性を提供します。これは、企業がデータセンターを統合し、ますます複雑化するインフラストラクチャを管理する上で特に価値があります。

同時に、AIはストレージ管理そのものを変革している。インテリジェントストレージシステムは現在、自動化されたデータ階層化、予測的最適化、さらには脅威検知といったタスクにAIを活用し、ストレージの自律性、回復力、セキュリティを向上させている。これらの機能が成熟するにつれ、ソフトウェア定義かつインテリジェントなストレージは、現代の組織が必要とする俊敏で将来を見据えたデータインフラ構築の中核となる。

明日のインテリジェントで持続可能なストレージエコシステムの構築

ストレージの未来は、容量以上のものを意味します。適応性、効率性、そして知性こそが鍵です。統合プラットフォーム、ハイブリッドアーキテクチャ、AI駆動型管理が、次世代データストレージの時代を定義する。同時に、持続可能性とコンプライアンスは最優先事項であり続け、技術選択と運用戦略の両方を形作る。

この環境を組織が切り拓く中で、イノベーションを受け入れ、パフォーマンス・コスト・環境責任のバランスを取る組織こそが、データ主導の世界で成功する最良の立場に立つでしょう。ストレージは単なるIT上の課題ではありません。明日のブレークスルーを築く基盤でだ。

タグ:

Microsoft 365 ユーザのためのMicrosoft Teams のバックアップの重要性

Microsoft Teamsのバックアップ方法を知ることの重要性

まず、Teamsのデータをバックアップすることがなぜ重要なのかを説明からスタートします。

その答えは、Teamsのバックアップが主に4つのリスクから保護するからです:

  • 業務中断:Teamsで管理されるデータが一時的または恒久的に利用不能になった場合に発生します。Teamsやその他のMicrosoft製品の停止は稀ですが、発生する可能性があります。例えば、不良なソフトウェア更新が引き金となり、多くのMicrosoft 365サービスを数時間にわたりオフラインにした2024年8月の大規模な障害を考えてみてください。
  • コンプライアンスリスク。DORAなどの規制枠組みでは、Teamsのようなオンラインプラットフォームに保存された情報を含む、すべてのデータを保護する計画の策定が企業に求められることが多くなっています。
  • ランサムウェア攻撃。脅威アクターがフィッシングなどの手法で企業のTeams環境へのアクセス権を取得し、保存されたデータを暗号化または削除する攻撃です。
  • 誤ったデータ削除。ユーザーがTeamsからファイルを誤って削除した場合に発生する可能性があります。

繰り返しになりますが、MicrosoftはTeamsをホストするインフラを管理しているものの、Teamsに保存されたデータが永続的に利用可能であることを保証するものではありませんビジネスデータと個人データを適切にバックアップする責任は、Teamsユーザー自身にあります

Teamsのネイティブなデータ保護機能について

Microsoft Teamsはすべてのユーザーデータを自動的に保護するわけではありませんが、いくつかのネイティブなデータ保護機能を備えています。主な機能は以下の通りです:

  • ごみ箱からのデータ復元: Microsoft Teamsにはごみ箱機能があり、保持期間が満了していない限り、ほとんどの種類のTeamsデータを復元できます。保持期間はケースによって異なり、組織はカスタムの保持期間を設定できます。通常、Teams データは 30 日間 復元可能ですが、管理者がデータ保持を完全に無効にしている場合、データは即時かつ完全に削除されます(データ保持ポリシーの詳細については、Microsoft ドキュメントを参照してください)。
  • バージョン管理:Teams のバージョン管理機能により、特定のファイルを以前のバージョンに復元できます。ただし、これは SharePoint に保存されたデータにのみ適用され、その他の種類の Teams ファイルには適用されません
  • Microsoft Purview: TeamsをMicrosoft Purview(データガバナンスおよびセキュリティツール)と統合すると、Teamsデータを一定期間保持するポリシーを作成できます。ただし、Purviewはデータ保護プラットフォームではありません。その主な目的はコンプライアンスや法的保持に関連する要件への対応であり、ほとんどのケースではすべてのTeamsデータを保護するものではありません。

場合によっては、これらの機能でTeamsから誤って削除したデータを復元できるかもしれません。しかし、これらは真のデータ保護とは程遠いものです。すべてのデータタイプをカバーせず、迅速な復元を可能にせず、通常は比較的短期間しかデータを保持せず、その後は永久に失われます(事前に別の場所にバックアップしていない限り)。

Microsoft Teamsのバックアップにおける主な課題

Teamsのバックアップは重要ですが、以下のような課題があるため、必ずしも容易ではありません:

  • 分散型アーキテクチャ: Teamsは他のMicrosoft 365サービスと連携し、それらのサービスを利用してほとんどのデータをホストしているため、Teamsのバックアップには複数のサービスからデータをバックアップする能力が必要です。
  • APIのパフォーマンス制限: TeamsにはAPIが存在し、組織はこれを利用してデータを自動的にコピーできますが、APIにはスロットリングや同期の不整合といった制限が課される場合があります。これによりAPIベースのバックアップが遅くなる可能性があります。
  • APIのコスト: Teams APIの使用量も場合によっては課金対象となります(Microsoftは2025年8月に一部のTeams APIを無料化しましたが、すべてではありません)。結果として、APIを使用したデータバックアップは高額なコストを招く可能性があります。
  • セキュリティ要件: 機密性の高いTeamsデータをバックアップする際は、セキュリティリスクを軽減するための特別な注意が必要です。例えば、保存されたログイン情報の悪用を防ぐため、バックアップ認証情報はテナント認証情報とは別個に管理すべきです。
  • データの完全な再現性の制限: データ復旧の一環としてTeamsデータを完全に再現することは、多くの場合容易ではありません(場合によっては不可能なこともあります)。例えば、リアクションやスレッドが失われる可能性があります。

後述するように、これらの課題のほとんどは解決可能です。ただし、Microsoft Teamsの固有のニーズに合わせたバックアップおよび復旧戦略を採用した場合に限ります。

Microsoft Teams バックアップのよくある間違い

Microsoft Teams のバックアップ方法に関わらず、以下のよくある落とし穴を避けてください:

データ復元機能のテストを怠る。復旧テストはあらゆるデータ保護シナリオで重要です。しかし、プラットフォーム内でのデータ復元方法に特有のニュアンスがあるTeamsでは、特に重要となります。

データ保持がバックアップ代わりになるとの誤解。 上記の通り、保持はデータを限定期間のみ保護し、完全な復元機能を提供しない場合があります。

プライベートチャネルの SharePoint サイトを見落とすこと。 包括的な Teams バックアップ戦略では、すべての Teams データを保護する必要があります。

会議のアーティファクトを見落とす。同様に、Teamsアーティファクト(ライブ会議やイベント中に生成されるデータ)のバックアップも重要です。

本番環境とバックアップで同じ認証情報を使用する。前述の通り、これはセキュリティリスクとなります。

Microsoft Teams のバックアップに関するベストプラクティス

Teams バックアップの効率性と信頼性を最大化するには、以下のベストプラクティスを考慮してください:

●Teams構成を変更したり、テナントを追加・削除したりするたびに、Teamsバックアップ戦略を再評価してください。

MFA を適用 して、Teams バックアップデータへの不正アクセスのリスクを軽減します。

別のバックアップ認証情報 を使用します。これにより、バックアップにアクセスできる者が、それらを使用して Teams にログインすることを防ぎます。

不変ストレージ を使用してバックアップを保存し、ランサムウェア攻撃によるバックアップデータの改ざんや削除を防ぎます。

●復旧訓練を通じてデータ復旧計画を定期的に検証してください。訓練は理想的に四半期に1回以上実施すべきです。

バックアップを継続的に監視してください。これにより問題が発生した際に通知を受けられ、Teams APIが原因のバックアップ性能問題を早期に発見できます。

Microsoft Teams のバックアップ方法 についてのまとめ

Microsoft が自動的に Teams データを保護してくれたり、他のプラットフォーム(SharePoint など)のバックアップで Teams データの損失を防げたりすれば理想的です。

しかし、残念ながら、現実はそうではありません。必要な時に確実に Teams データを利用できるようにする唯一の方法は、Teams に特化したバックアップ戦略を設計・実装することです。手動やカスタムスクリプトでも実現可能ですが、より簡便で信頼性の高い方法は、クライムが取り扱うMicrosoft365専用のバックアップソリューションの利用です。

タグ: ,

SharePointのバックアップ方法:IT管理者向けガイド

SharePointのバックアップがこれまで以上に重要である理由: SharePointの容量が足りない!

まず、SharePointデータのバックアップそのものの重要性について議論しましょう。

SharePointオンラインのバックアップを作成する必要性は、ビジネスオーナーやSharePointサイト所有者があまり考えないことかもしれません。MicrosoftによるSharePointの管理は、データバックアップと復元が含まれているという誤った印象を与える可能性があります。

しかし現実には、マイクロソフトの責任範囲に関するポリシーに基づき、マイクロソフトが保護するのはホストインフラストラクチャのみです。同社の公式見解によれば、「SharePointおよびOneDrive for Microsoft 365にデータを保存する場合、データ所有権はお客様に帰属します」とされています。これは、基盤となるSharePointインフラが健全であっても、データ損失につながる脅威からの保護責任はお客様(顧客)が負うことを意味します。

SharePointをバックアップすべき6つの理由

脅威は様々な形で発生します。例えば:

  • 誤ったデータ削除:従業員や契約社員がSharePointからファイルを削除した場合、データは永久に失われる可能性があります。通常、93日間はデータを「復元」できます(ただし、SharePointのプランやデータの種類によって異なります)。この期間を過ぎると、手元にSharePointのバックアップがない限り、復元する方法はありません。
  • 内部脅威:同様に、社内の悪意ある内部関係者が、企業に損害を与える目的で意図的にデータを削除する可能性があります。SharePoint内で復元できる保証はありません。
  • ランサムウェア:環境へ侵入したランサムウェア攻撃者は、SharePointデータを削除または暗号化した後、アクセス回復の身代金を要求します。バックアップがあれば身代金を支払わずにデータを復元可能です。これは重要な対策です。なぜなら、身代金を支払った企業のうち20%のみがデータを完全に回復できているという報告があるからです。
  • バージョン管理の不足:SharePointには文書を複数バージョン自動保存するバージョン管理機能が組み込まれています。しかし全ての変更を永続的に保存するわけではなく、想定外の状況が発生する可能性があります。例えば、SharePointが保持する最新バージョンよりも古い文書が必要になった場合、復元にはバックアップが不可欠です。
  • コンプライアンス要件:HIPAAやGDPRなどの規制では、SharePointの標準サポート期間を超えるデータ保持が求められる場合があります。こうした要件を満たすためにも、バックアップは重要です。

最後に重要な点として、SharePoint Online 自体が一時的に障害を起こす可能性があります。SharePoint のサービス停止は稀ですが、特に業務中断による収益損失のため、非常に大きなコストが発生します。SharePoint やその他の Microsoft 365 サービスの障害は、1時間あたり100万ドルもの損失をもたらす可能性がありとのレポートもます。

SharePointでバックアップすべきデータ

効果的なSharePointのバックアップと復旧戦略では、SharePointに保存されているすべてのデータを対象とします。これは文書やその他の標準的なファイルタイプだけではありません。包括的なバックアップでは、以下の項目も保護する必要があります:

  • サイト、サブサイト、ライブラリ。
  • ファイルをTeams、OneDrive、その他の外部プラットフォームやサービスにリンクする設定。
  • ファイルのバージョン履歴。

SharePointサイトからこれらの情報をすべて復元できない場合、バックアップは事業継続性を確保する上であまり役に立ちません。バックアップにファイルとユーザーアクセスに必要な基本統合のみが含まれている場合、復旧にはどれほどの時間がかかるでしょうか?そのプロセスは数週間かかる可能性があります。しかし、SharePointコンテンツ自体とともにバックアップすれば、SharePointデータをコンテキストを完全に保持した状態で自動的に復元できます。

Microsoftのネイティブバックアップツールでできること、できないこと

Microsoftは、SharePointデータの保護を限定的に提供するさまざまな組み込みツールと機能を提供しています。例えば、前述したように、ほとんどのケースで最大93日間、SharePointのごみ箱からファイルを復元できます。同様に、バージョン管理機能により、必要なバージョンが自動的に保存されている場合、古いファイルバージョンを復元できます。

さらに、SharePointにはeDiscoveryおよびコンプライアンス機能が含まれており、特定のファイルタイプの自動保存を強制するのに役立ちます。

これらの機能は、SharePointにおける非常に基本的なデータバックアップと復元ニーズを満たす上で確かに有用です。しかし、重大な制限があります。何よりも、あらゆる種類のデータを保護するわけではなく、データの保持期間を完全に制御することもできません。自動データ復旧機能も備えていないため、大量のファイルを復元する必要がある場合には不十分な解決策となります。

代わりに、Microsoftのネイティブバックアップ機能は主にデータ保持機能に過ぎず、データ保持は真のバックアップとは異なります。

手動およびローカルの SharePoint バックアップについて

ローカルストレージを使用して手動でバックアップを作成することで、SharePointの基本的なバックアップ要件を満たすことも可能です。例えば、ドキュメントライブラリをPCのハードドライブにダウンロードしたり、ローカルストレージにマッピングされたOneDriveインスタンスとSharePointファイルを同期したりできます。カスタムPowerShellやPower Automateワークフローを使用してデータをローカルストレージに自動的にバックアップすることも可能です(ワークフローを自身で実装できる場合に限ります)。

ただし、これらの手法も基本的なSharePointバックアップ要件を満たすのに役立つに過ぎません。ドキュメントのバージョン履歴など、一部のデータタイプが対象外となるため完全な保護には至りません。さらに自動化機能は限定的で、自動化を実装する場合でもエラーが発生しやすいスクリプトを手動で記述する必要があります。

クラウド間データ保護によるSharePointバックアップの自動化

前述の煩雑で信頼性の低いデータ保護手法に代わる選択肢があります。クラウド間バックアップと呼ばれるこの手法では、すべてのSharePointデータを別のクラウドベースのストレージプラットフォームに自動的にコピーします。

このアプローチには以下のような利点があります:

  • より信頼性の高いストレージ: クラウドストレージはローカルディスクやストレージアレイよりも障害が発生しにくい。
  • 無制限のストレージ容量: クラウドではストレージ容量が不足することはありません。
  • 継続的なバックアップ: クラウド間SharePointバックアップでは、Microsoft Graph APIを通じて本番サイトとバックアップを常に同期させられます。
  • 増分バックアップのサポート: 特定の期間のみデータをバックアップしたい場合、増分バックアップも選択肢となります。
  • 高速な自動復元: クラウド間バックアップでは、クラウドから直接SharePointデータを自動的に復元するオプションが提供され、通常はローカルストレージからの復元よりも高速です。
  • 完全なデータカバレッジ: APIを使用することで、ファイルだけでなくあらゆる種類のSharePointデータをバックアップできます。

これらの理由から、外部ツールを用いたクラウド間バックアップは、大規模なSharePointの自動化に最適な方法です。他の方法は、ほんの一握りのファイルのみを保護する場合にのみ適しています。

こうした状況を踏まえると、88%の企業がサードパーティ製SharePointバックアップツールを好むと回答しているのも当然でしょう。

SharePointバックアップソリューションで重視すべき主要機能

優れたSharePointバックアップソリューションは、単なるクラウド間バックアップ機能や大規模なバックアップ・復旧操作の自動化機能以上のものを提供します。SharePointデータの安全性を確保するには、サイト、サブサイト、ライブラリなどを完全にカバーするツールを選択することも重要です。

広範なバックアップ設定オプションも重要です。ニーズに応じて粒度の細かいバックアップとサイト全体のバックアップおよび復元を選択できる必要があります。また、信頼性の低い一括エクスポートオプションではなく、APIベースのバックアップをサポートすることも目標とすべきです。さらに、ツールはカスタム保存ポリシーの設定オプションを提供し、法的保持要件を満たす必要があります。

セキュリティの観点からは、データのエンドツーエンド暗号化を提供するSharePointバックアップツールを探しましょう。これにより、SharePointサイト内の機密データはバックアップおよび復元プロセス全体を通じて暗号化され、安全に保護されます。多要素認証役割ベースのアクセス制御も、バックアップデータへの誤ったアクセスを防ぐのに役立ちます。

コストも重要な検討事項です。ここでは、SharePointバックアップツールのライセンス費用(これも重要ですが)だけでなく、選択したクラウドプラットフォームにバックアップを保存することで「クラウドの持ち込み」が可能かどうかを考慮すべきです。可能であれば、低コストのクラウドストレージサービスを活用できるため、費用を抑えられる可能性が高いです。ベンダーが特定のストレージを強制する場合、SharePointデータを保護するためのギガバイトあたりのコストが高くなる傾向があります。

最後に、バックアップソリューションの導入と管理の容易さを検討してください。単一のハブを通じてバックアップを一元的に設定・監視する機能は、ITスタッフの運用を簡素化します。レポート機能も、バックアップのステータスを追跡し問題を検出する手段として重要です。

Climb Cloud Backup for Microsoft 365 が SharePoint を保護する方法

SharePointおよびその他のMicrosoft製品向けに特別に構築されたデータ保護プラットフォームとして、Climb Cloud Backup for Microsoft 365は、上記で説明したすべての主要なSharePointバックアップ機能を提供します。これには以下が含まれます:

  • ローカルストレージを必要としない完全なクラウド間バックアップアプローチ。
  • バックアップ操作はMicrosoft Graph APIを使用してデータを要求・移動するため(SharePointの単純なデータエクスポート機能ではなく)、高度にカスタマイズ可能で安全かつ効率的なバックアップを実現します。
  • アイテム単位の細かなデータ復元と、SharePoint データ全体の完全な復元を完全にサポート。
  • あらゆるクラウドにデータを保存できるため、プロプライエタリなストレージとそれに伴う高額なコストを回避可能。
  • IT管理者がバックアップを一元管理できる集中管理コンソール。
  • マルチテナント対応により、単一のバックアップツールで複数クライアントのSharePointバックアップを容易に実現。
  • 保存時データと転送中データの完全暗号化、多要素認証、監査ログ機能による強化されたセキュリティ。

Microsoft 365 SharePoint バックアップのベストプラクティス

使用するバックアップツールに関わらず、以下の手順でSharePointデータの保護を効率的かつ確実に維持できます

SharePoint、OneDrive、Teamsのバックアップを統一管理他のMicrosoftサービスを利用している場合、単一のバックアップツールと保存場所を採用することで運用を簡素化し、コスト削減が可能です。

バックアップスケジュールと保存期間はデータ要件に基づいて設定する異なるデータは、必ずしも同じ頻度や保存期間でバックアップする必要はありません。各SharePoint資産の重要性を評価し、それに基づいてバックアップと保存計画を作成してください。重要度の低いデータは、頻繁にバックアップする必要はありません。

データ復元を定期的にテストする災害発生後にSharePointバックアップが正常に復元できないことに気付く事態は避けたいものです。復元テストを実行して復旧計画を検証し、このリスクを回避してください。

バックアップ認証情報をMicrosoft認証情報から分離するバックアップツールへのアクセス用認証情報は、Microsoft 365アカウントへのアクセスに使用するものと異なるものを使用してください。これにより、Microsoftアカウントが侵害された場合でも、異なる安全な認証情報を必要とするため、バックアップの安全性が保たれます。

バックアップの監視と監査不安定なネットワーク接続によるデータ操作の失敗など、様々な要因がSharePointバックアップを妨げます。バックアップを監視・監査し、障害を早期に把握することで、データ復旧時の予期せぬ事態を回避しましょう。

結論

要するに、SharePointは非常に信頼性の高いプラットフォームですが、データ損失を引き起こす可能性のあるあらゆるシナリオに対して自動的に保護するわけではありません。共有責任モデルにおける自社の責任を果たすためには、SharePointデータのバックアップと復旧計画の策定が必要です。

理想的には、クライムが提供する専用バックアップツールを使用してこれを行うべきです。これにより、スケーラブルで効率的なクラウド間バックアップと復旧が可能となり、コンプライアンスと事業継続性の態勢を最大限に高めることができます。

タグ: , , ,

クラウドコンピューティングと災害復旧:ハイパースケーラーの隠れたリスク

2025年10月20日深夜、AWSの最重要リージョンであるUS East-1が停止し、インターネットの半分のサービスがダウンしました。DynamoDBにおけるDNS競合状態が引き金となり、EC2インスタンスの障害、S3バケットへのアクセス不能、広範なサービス停止へと拡大しました。SnapchatやAsanaといったアプリはもちろん、一部の銀行システムや政府システムまでもが、約15時間にわたり機能停止に陥った。大小さまざまな企業が生産性、収益、顧客の信頼を失いました。

AWSは最終的に問題を「修正」したが、被害は既に発生していました。IT部門、自動化チーム、事業継続チームにとって、これは単なる一時的な障害ではなかった。システム的なリスクに対する警鐘でした。

その9日後、世界第2位のクラウドプロバイダーであるAzureも重大な障害に見舞われた。今度は別の人的ミス(設定変更とも呼ばれる)が原因で、Microsoft 365、Xbox、主要航空会社のチェックインポータルを含むサービスが停止しまた。

結局のところ、最も成熟したグローバルハイパースケーラーであるAWSとAzureでさえ数時間に及ぶサービス停止が発生するならば、それらに依存する我々にとってそれは何を意味するのか?

この一連の出来事から得られた一つの良い点は、長年続いてきた災害復旧に関するいくつかの神話が、ついに終焉を迎えたことです。

神話その1:マルチAZは「十分」である

AWSのスナップショットとS3バックアップは、複数のアベイラビリティゾーン(AZ)に複製され、最大99.99999%の信頼性を実現するため、高い耐久性を備えています。これは素晴らしいことですが、多くの組織は、単一リージョン内のAZにワークロードを分散させるだけで耐障害性が確保されると考えていました。

East-1の障害は、この考えが誤りであることを証明しました。リージョン全体が障害を起こすと、その内部のすべてのAZが停止し、最善のアーキテクチャで構築されたデプロイメントでさえも到達不能になります。

複数のAZにまたがるスナップショットとS3バックアップの使用は依然としてベストプラクティスですが、それは解決策の一部に過ぎません。真の保護には、リージョン災害から守るためのリージョン間およびアカウント間のレプリケーションが必要です。

神話その2:DR(災害復旧)の見直し時期——マルチクラウドが答え

大規模なシステム障害のたびに、反射的な反応はいつも同じです:「すべてを再構築しよう。マルチクラウドに移行する時だ」と

確かに、それは魅力的に思える。復旧作業の約80%は単純で、削除された数ファイルや主要インスタンスの復元です。こうした作業は手動またはサードパーティツールで対応できる。しかし10月20日の事象は、全てが同時に機能停止した際の手動復旧がいかに脆弱かを露呈しました。

現実問題として、マルチクラウドバックアップやクロスクラウドDRは即効性のある解決策ではない。複数のコンソール管理、急峻な学習曲線、新たなコンプライアンス監査、予測不能なデータ転送コストなど、膨大な複雑性を伴います。

より賢明で実用的なアプローチは、現在のクラウド環境を維持しつつ、クロスリージョンレプリケーション(リージョン全体の障害対策)とクロスアカウントDR(マルウェアやランサムウェア対策)で戦略を強化することです。これは多くのチームが認識している以上にシンプルで制御しやすく、はるかに費用対効果が高い手法です。同時に、大規模なリージョン障害時でもデータとワークロードの可用性を維持できます。

神話その3:クロスリージョンおよびクロスアカウントDRは高すぎる

ITチームが複製レイヤーの追加を躊躇する最大の理由はコストでしょう。

しかしクロスリージョンDRはクラウド費用を倍増させるわけではありません。ITチームは利益重視のCFOや経営陣にこの点を明確に伝える必要があります。増分バックアップと階層型ストレージ(例:AWS S3 Glacier、AWS Intelligent-Tiering、Azure Blob)を活用することで、クロスリージョンDRのコストは通常、クラウド総支出のわずか5~15%に収まります。

これは、グローバルSaaSアプリケーション、銀行システム、または重要なビジネスサービスにおいて、たった1時間のダウンタイムが発生した場合の損失額と比較すれば、誤差の範囲に過ぎません。

神話その4:SaaS型DRツールが救ってくれる

AWSの障害発生時、多くのチームは直感的にSaaS型災害復旧ツールにログインし、システムの復旧を開始しました。しかし問題は?そのSaaSツール自体もダウンしていたのです。DRソリューションが同じ外部インフラに依存している場合、地域的な障害が発生すると無力化されてしまいます。

これが、Infrastructure-as-a-Service(IaaS)DRツールが不可欠な理由です。バックアップサーバーが自社環境に設置され、すべてのバックアップに直接アクセスできる場合、外部サービスへの依存は発生しません。他者のシステムが復旧するのを待つことなく、いつでもあらゆるものを復元できます。復旧ツールは、必要な時にいつでも利用可能です。

神話その5:DR計画の構築には数か月が必要

インフラ全体を一から作り直す必要はありません。停電時にパニックに陥った企業もあれば、そうならなかった企業も多数存在します。その違いは?冷静さを保った企業は、地域別の復旧手順書を用意していました。重要なデータは自動的に地域やアカウント間で複製されており、停電が発生した際には単に計画を実行しただけです。

すぐに実践できる4つの具体的な手順:

1.退屈になるまでテストする。15分で復旧した企業は必ずしも最も洗練されていたわけではない——単に最も準備が整っていただけだ。筋肉記憶が確立されていたからこそ、迅速に復旧できたのである。

2. SaaSではなくIaaSベースのDRツールを活用する。これにより、復旧インフラが障害発生地域に依存しなくなる。

3. ネットワークスタック全体を復旧対象とする。サーバーの性能は接続する仮想ケーブルの性能に依存する。サブネット、ルーティングテーブル、セキュリティグループ、ロードバランサーなど、基本的に全てのネットワーク設定を複製・準備しておくことで、設定エラーによるフェイルオーバーの停滞を防ぐ。

5. テストを自動化する。リソースを優先順位付けし、訓練をスケジュールし、成功の完全な可視化のためのレポートを生成するDR訓練とテストツールを活用する。

障害発生後の実践的な教訓

クラウドバックアップと災害復旧は、近所の道路が舗装工事中だと考えてみてください。工事で一時的に道路が封鎖された場合、わざわざ迂回路を新設する必要があるでしょうか? それとも、車両が通行できる明確な経路を確保し、交通が迅速に再開される保証さえあれば十分ではないでしょうか。

AWSの障害は偶然ではない。ハイパースケーラーの利便性にはシステム的な脆弱性が伴うという事実を改めて認識させる出来事だった。結局のところ、回復力の責任はプロバイダーではなくあなた自身にある。問題はAWSやAzure、GCPが障害を起こすかどうかではなく、障害発生時に15時間も待てる余裕が自社にあるかどうかだ。

編集後記

Azure対応 移行・連携・データ保護 特集ページ

AWS対応 移行・データ保護 特集ページ

ランサムウェア対策:Active Directoryセキュリティ設計図

ランサムウェア攻撃は依然として深刻な問題です。2025年に入り報告されたセキュリティホール(CVE)が急増しており、あらゆるプログラムやサービスを絶え間なくパッチ適用・更新し続ける必要性が浮き彫りになっています。新たなITツールやシステムの導入はこれをさらに困難にし、管理業務の増加と古い技術的負債の積み上げを招いています。

ある調査会社によれば、ランサムウェア被害の90%以上がMicrosoftベースの環境を標的としています。現代の攻撃は体系化され、多段階にわたり横方向の移動、権限昇格を焦点とし、最終的にはActive Directoryを主目標とする基幹システムの完全な侵害を目指します。したがって、多層的なセキュリティ計画の構築が不可欠です。

ここでは、各ランサムウェアグループが現在用いる侵入手法を検証し、システムを大幅に強化する対抗策を共有します。

一般的な攻撃ベクトル

では、ランサムウェアは通常どのように侵入するのでしょうか?あらゆる侵害は一つの脆弱なリンクから始まり、これらの侵入経路を理解することが強固な防御構築の助けとなります。最も一般的な攻撃ベクトルを見てみましょう:

公開されたRDP/VPNアクセス

公開されたリモートアクセスは、しばしば最初かつ最も重大な弱点となります設定ミスやパッチ未適用のリモートアクセスサービス(RDP、Ivanti、Fortinet、Citrix)は、依然として最も一般的な初期アクセスベクトルです。パブリックRDPアクセスの無効化、SMTP/VPNゲートウェイでのMFAと地理的ブロックの徹底により、曝露リスクを大幅に低減できます。

レガシープロトコルの悪用

パスワードスプレー攻撃やブルートフォース攻撃が成功するのは、古いプロトコル(POP3、IMAP、SMTP AUTH、MAPI over HTTP)にフィッシング耐性のあるMFA(多要素認証)が欠如しているためです。攻撃者はこれらの手法をクレデンシャルスタッフィングと組み合わせて、他のサービスから漏洩した認証情報をEntra ID(Azure AD)やADFSなどのSSOポータルに悪用することが多くあります。

N-day脆弱性

ワンデイ(またはn-day)脆弱性とは、パッチや緩和策が既に存在するにもかかわらず適用されていない既知のセキュリティ欠陥を示します。「ワンデイ」という用語は、脆弱性が公表されてから影響を受けるシステムが更新されるまでの期間を意味します。実際にはこの期間が長引くことが多いため、「n-day」という別称が用いられます。

公開アプリケーション、ロードバランサー、Webサーバー、コラボレーションツールは、CVE公開後数時間以内に標的とされることが多く、迅速にパッチを適用しない場合、高いリスクを伴います。

ソフトウェアサプライチェーン攻撃

ソフトウェアサプライチェーン攻撃は、開発者、ツール、サードパーティコンポーネント間の信頼関係を悪用します。ライブラリ、リポジトリ、CI/CDパイプラインを侵害することで、攻撃者は正当なソフトウェア更新を通じて拡散する悪意のあるコードを注入できます。信頼されたソースから侵入するため、これらの攻撃は検出が困難であり、厳格な依存関係管理、署名付きビルド、完全性チェックが防御に不可欠です。

悪意のある電子メール添付ファイルとリンク

フィッシングメールは、攻撃者にとって最も一般的な侵入経路の一つであり続けています。これらは感染したWordやExcelファイル、または開くと悪意のあるコードを起動するリンクを頻繁に含んでいます。目的は通常、ユーザのデバイスを侵害し、認証情報を窃取するか、ネットワーク内に足場を築くことです。訓練されたユーザでさえ、ソーシャルエンジニアリングや正当なビジネス通信を模倣した説得力のあるメッセージによって騙される可能性があります。

Active Directory攻撃

最終的に内部に侵入すると、攻撃者は焦点をActive Directoryに移します。KerberoastingAS-REP RoastingGolden Ticket攻撃などの手法により、権限昇格と持続的侵入の維持が可能になります。侵害されたADは、多くの組織にとって「ゲームオーバー」の瞬間です。

ランサムウェア攻撃は本質的に機会主義的であり、最も脆弱な標的を探します。多くの場合、組織は新たに発見された脆弱性(N-day脆弱性)が悪用され、初期アクセスを得ることで侵害されます。

対策

では、どのような対策を講じるべきでしょうか?悲しい現実として、ランサムウェアを完全に阻止できる単一のツールは存在しません。目標は、環境を侵入困難かつ復旧容易にすることです。この場合、IDセキュリティ、システム強化、確実な復旧に焦点を当てた多層防御こそが、唯一持続可能なアプローチです。

フェーズ1:IDファーストセキュリティ

攻撃者はファイアウォールではなく、まずIDを狙います。ハードウェアキー(FIDO2/WebAuthn)、スマートカード、または証明書ベース認証を利用したフィッシング耐性のあるMFAは、全ユーザー(特に管理者)に必須です。

テナントレベル(Entra ID、Exchange Online)で全てのレガシー認証プロトコルを無効化

これによりパスワードスプレー攻撃の大半を遮断

特権アクセス管理(PAM)はAzure PIM等のツールを通じ一時的なJIT権限を発行し最小権限原則を強制。攻撃者が恒久的に窃取できる対象を排除

ADとEntra IDの強化により、一般的な攻撃経路を排除します:

  • オンプレミスの管理者アカウント(例:ドメイン管理者)をEntra IDに同期しない
  • 階層型管理モデルを導入し、特権アカウントを分離
  • ADグループメンバーシップの閲覧権限を制限
  • 脆弱なKerberos設定を監視・修正
  • インシデント対応訓練を定期的に実施し、ID侵害発生時に即座に対応できる体制を確保

フェーズ2:内部強化とゼロトラスト

「侵害を前提とする」ゼロトラストの考え方を採用するには、ネットワーク内部を外部と同様に厳重に保護する必要があります。これには3つのアプローチが必要です:アクセス制限の強化、全エンドポイントの堅牢化、侵入した脅威の検知です。

1. ゼロトラストネットワークアクセス(ZTNA)の適用

まず、横方向の移動を困難にします。特にドメインコントローラーなどの重要システムを隔離し、安全な管理用ワークステーションまたはジャンプホストからのみアクセス可能にします。侵害されたマシンがC2サーバーに到達するのを防ぐため、アウトバウンドトラフィックを制限します。

ゼロトラストアクセスソリューション(Microsoft Conditional Access、Cloudflare Access、Zscaler ZPAなど)でユーザレベルでこれを強制します。これにより、健全で管理されたデバイスのみが内部サービスにアクセスできるようになります。

2. すべてのエンドポイントとサーバーを強化

エンドポイントは主要な戦場です。全ユーザーのローカル管理者権限を削除してください。セキュリティベースライン(MicrosoftやCISベンチマークなど)を適用し、攻撃対象領域削減(ASR)ルールを展開します。最低限以下の対策を実施:

  • Officeアプリケーションの子プロセス生成をブロック
  • メールクライアント/ウェブメールからの実行可能コンテンツをブロック
  • 署名なし/信頼できない実行ファイルをブロック
  • JavaScript/VBScriptによるダウンロードコンテンツの実行をブロック

さらに攻撃経路を削減するため、インターネットからのマクロをブロックし、危険なファイルタイプ(HTA、JS、VBS)をメモ帳で開くよう強制し、ブラウザを集中管理して安全でない拡張機能をブロックします。

3. 継続的検知と対応の実装

侵入者を検知できる体制が必要です。エンドポイント検知・対応(EDR)またはXDRツールを導入し、資格情報の窃取、不審なプロセス、メモリ注入の兆候を監視します。これらのツールは自動的に悪意のあるマシンを隔離できます。

ドメインコントローラー、ファイアウォール、ID管理システムからのログを中央SIEM(Azure SentinelやRapid7 InsightIDRなど)に送信し、横方向移動の初期兆候を捕捉します。最後に、既知の悪意あるドメインをブロックするため、すべてのDNSをフィルタリングサービス(Quad9やCisco Umbrellaなど)経由でルーティングします。

フェーズ3:確実な復旧

最強の防御策でも失敗はあり得ます。「3-2-1-1-0」ルールに基づく回復力のあるバックアップ戦略こそが、インシデントが短期間の混乱で終わるか、事業終焉の危機となるかを決定づけます。

  • データの3重コピー 稼働用コピー1部とバックアップ2部を保持。
  • 2種類の異なるメディア 少なくとも2種類の異なる技術(例:ディスクとクラウド)にバックアップを保存。
  • 1xコピーをオフサイトに。地理的に分離したバックアップを少なくとも1つ維持する。
  • 1xコピーをオフラインまたは不変状態に。これがランサムウェア対策の要です。バックアップはエアギャップ化または不変状態(例:オブジェクトロックやWORMストレージ経由)でなければなりません。攻撃者はアクセスできないものを暗号化も削除もできません。
  • 復元検証におけるエラーゼロ。テストされていないバックアップはバックアップではない。完全性を検証するため、定期的な自動復元テストを実施する。

充実した復旧計画には、VPN、ファイアウォール、バックアップソフトウェア、ハイパーバイザーを含む全システムに対する積極的なパッチ管理も含まれます。バックアップインフラ自体も本番環境の認証から隔離し、異常を監視する必要がある。不変かつ検証可能なバックアップこそが、ランサムウェア被害を一時的な問題に抑えられるか、永久的な損失となるかを決める最終防衛線です。

結論

忘れないでください。ほとんどのランサムウェア攻撃は、従来のオンプレミスADとファイル共有環境に依存しています。エンドポイントをクラウドネイティブのEntra ID(Azure AD)モデルに移行することで、この攻撃チェーンと脅威アクターが構築したロジックの大半を効果的に断ち切れます。攻撃者が侵害されたクライアントから重要なサーバーインフラへ移動するために使用する主要な横方向移動経路を遮断するのです。

環境を保護する方法を理解した上で、攻撃者に機会を与えないよう、これらの手順を直ちに適用してください。

クライム・ランサムウェア対策 特集ページ

タグ: , , , , , ,

ブロック・ストレージとオブジェクト・ストレージ:その違いは?

データストレージはあらゆるコンピューティングの基盤であるが、その扱い方は劇的に変化した。当初はローカルディスク上の単純なファイルシステムから始まり、このモデルはパーソナルコンピュータに十分対応していた。しかしデータ量が爆発的に増加し、アプリケーションの要求が高まるにつれ、基盤となるストレージアーキテクチャは進化を余儀なくされた。

物理レベルでは、あらゆるストレージはブロックで構成されています。ドライブは固定サイズのチャンクでデータを保存し、上位システムがそれらのチャンクに構造と意味を与えます。この概念から、2つの主要なネットワークストレージアーキテクチャが生まれました:ブロックストレージオブジェクトストレージです。

ブロックストレージは一貫した低遅延性能を提供し、データベースや仮想マシンの基盤となっています。一方、クラウドの拡張性と柔軟性のために構築されたオブジェクトストレージは、現代のアプリケーションやサービスを駆動する膨大な非構造化データに対して、圧倒的な耐久性と効率性を提供します。ファイルストレージは共有ユーザーデータやアプリケーションデータにおいて依然として役割を果たしていますが、今日のデータセンターの中核を支えているのはブロックストレージとオブジェクトストレージです。

両者の違いを理解することは、スケーラブルで耐障害性が高く、コスト効率の良いシステムを設計する上で鍵となります。両者の相違点、それぞれの優位性、適切な選択方法について解説します。

ブロックストレージとは?

ブロックストレージはハードウェア層に最も近い位置にあります。OSに対して論理ディスクとしてストレージボリュームを提示し、OSはこれをパーティション分割し、ファイルシステム(NTFS、ext4、XFSなど)でフォーマットし、ローカルドライブのようにマウントできます。

番号付きの棚が並ぶ倉庫と想像してください。ストレージシステムは格納内容に関心を持たず、棚番号のみを追跡します。OSがデータを書き込む際は「101番から103番の棚に格納せよ」と指示し、読み戻す際は該当棚を指定するだけです。この直接アクセス特性により、ブロックストレージは高性能・低遅延を要するワークロードに最適です。

直接的なランダムアクセス

ブロックは他のブロックに影響を与えずに独立して読み書きできます。大規模データベース内の単一セルを変更する場合、影響を受けるブロックのみが書き換えられ、ファイル全体が書き換えられることはありません。この効率性こそが、データベース、VMディスク(VMDK、VHDX)、その他のパフォーマンスが重要なシステムなどのトランザクションワークロードを支えるブロックストレージの基盤となっています。

ファイルシステムへの依存

ブロックストレージ自体はファイルやフォルダを理解しません。人間が理解できるファイル構造を基盤となるブロックにマッピングするのは、その上に構築されたファイルシステムです。この緊密な統合により、アプリケーションは標準的なファイルI/Oを通じてブロックストレージをローカルドライブのように使用できます。

強固な一貫性

ほとんどのエンタープライズ向けブロックシステムは、データが安全に保存されるか冗長メディアにミラーリングされた後にのみ書き込みを確定します。ジャーナリングや書き込み事前記録(WAL)などのメカニズムにより、書き込みが承認されると、データは直ちに一貫性を持って後続の読み取りに利用可能になります。これはトランザクションの整合性にとって極めて重要です。

オブジェクトストレージとは?

オブジェクトストレージは全く異なるアプローチを採用します。固定サイズのブロックを管理する代わりに、データをオブジェクトと呼ばれる自己完結型の単位として扱います。各オブジェクトには以下がまとめられます:

  1. データ本体(写真、動画、ログ、バックアップなど)
  2. そのデータを記述する豊富なメタデータ(タイプ、サイズ、作成日時、タグ)
  3. グローバルに一意の識別子(オブジェクトID)。

オブジェクトストレージは、データのバレットパーキングシステムと考えることができます。ファイルを預けると引換券(ID)を受け取り、保存場所を知る必要はありません。再度要求すると、システムは即座にそれを見つけます。メタデータは引換券のメモとして機能し、何をいつ保存したかを記述します。

フラットなアドレス空間とAPIアクセス

オブジェクトストレージは従来のフォルダ階層を排除します。全てのオブジェクトはフラットな論理ネームスペース内に存在し、通常はバケットまたはコンテナに組織化されます。ディレクトリを辿る必要がないため、この構造はほぼ無限に拡張可能です。オブジェクトへのアクセスは、GET、PUT、DELETEなどのコマンドを用いたHTTP経由のRESTful APIを介してプログラム的に行われます。このAPI主導の設計が、クラウドネイティブ環境における自然な選択肢となっています。

耐久性と冗長性

耐久性は中核原則です。オブジェクトシステムはRAIDに依存せず、レプリケーションまたはエラー訂正符号化を採用します。レプリケーションは各オブジェクトの完全コピーを複数ノード/サイトに分散保存し即時可用性を実現。エラー訂正符号化はオブジェクトをフラグメントとパリティブロックに分割しクラスター全体に分散するため、複数ドライブ/ノード障害時でも復旧可能です。完全レプリケーションよりオーバーヘッドを抑えながら高い耐障害性を達成します。

不変性とバージョン管理

多くのオブジェクトシステムは不変性をサポートし、定義された保持期間中はオブジェクトの変更や削除ができません(WORM)。これにより、バックアップやアーカイブをランサムウェア、誤削除、時には不正なシステム管理者の操作から保護します。バージョン管理はこれをさらに発展させます。オブジェクトが更新されると、古いバージョンを上書きする代わりに新しいバージョンが作成されます。以前のバージョンはアクセス可能なまま維持され、完全なデータ履歴と復旧オプションを保証します。

例えば、DataCore Swarmはバージョン管理とWORMポリシーを組み合わせ、改ざん防止機能を備えた不変オブジェクトストレージを実現します。

ブロックストレージとオブジェクトストレージの主な違い

データストレージアーキテクチャ:ブロック対オブジェクト

選び方

いつものように、どちらが「優れているか」ではなく、アプリケーションに合っているかが重要です。自問してください:

  • アプリケーションはどのようにデータにアクセスしますか?: ボリュームをマウントしてファイルシステムを使用するアプリケーション(SQLやVMwareなど)にはブロックストレージが必要です。Web APIを使用するクラウドネイティブアプリケーションにはオブジェクトストレージが自然に適合します。
  • I/Oパターンは?: 毎秒数百万回のランダムな小規模読み書きにはブロックストレージが適しています。ビデオやバックアップのようなシーケンシャル書き込みやストリーミングワークロードにはオブジェクトストレージが効果的です。
  • 必要なスケーリングの種類は?: SANに数テラバイトを追加する必要がある?ブロックストレージが対応します。耐久性要件のあるペタバイト規模、地域横断、クラウド間での拡張が必要?そこではオブジェクトストレージが真価を発揮します。

現代の環境では、両者が共存するのが一般的です:高性能ワークロードにはブロックストレージ、大規模で耐久性が必要なデータにはオブジェクトストレージを採用します。

クライムとStarWindが提供できる支援

高性能ブロックストレージ向け:

StarWind Virtual SAN (VSAN)は、仮想化環境およびハイパーコンバージド環境向けに、低遅延・高可用性を備えた共有ブロックストレージを提供します。ノード間でデータをミラーリングし、ハードウェア障害時でもデータベースやVMをオンライン状態に維持します。

結論

議論はブロック対オブジェクトではなく、ブロックとオブジェクトです。バランスの取れたストレージ戦略において、それぞれが異なる役割を果たします。ブロックストレージは高速なトランザクションシステムを支え、オブジェクトストレージは長期的なスケーラビリティ、耐久性、データ保護を提供します。

それぞれの適所を理解することで、現在の高性能なインフラ設計と将来のスケーラビリティを両立させることが可能になります。

タグ: , ,

NISTコンプライアンスについて

ほぼすべてのIT専門家は、サイバーセキュリティが重要であることを認識しています。しかし問題は、脅威から保護するためにどの実践と手順に従うべきかということです。

NIST準拠は、この疑問を明確にする一つの方法です。NISTのサイバーセキュリティ推奨事項に準拠することで、IT専門家はITセキュリティを強化できます。

さらに、NIST準拠は特定の組織と取引する際に必須となる場合もある。米連邦政府機関の大半がベンダーにNIST準拠を要求しているためです。

ここでは、NIST準拠の意味、準拠が義務付けられる/推奨される対象、NIST準拠のために組織が実施すべき主要なセキュリティ対策と実践について解説する。

NIST準拠とは何か?

NIST準拠とは、米国国立標準技術研究所(NIST)が定めたサイバーセキュリティ推奨事項に従う実践を指します。

NISTは米国政府内の組織であり、科学技術関連の標準を開発しています。これには「NISTサイバーセキュリティフレームワーク(CSF)」として知られる一連のサイバーセキュリティ標準が含まれます。フレームワークの最新主要バージョンであるNIST 2.0は2024年に発表されました。

NIST準拠の対象となるのは?

NIST準拠は主に以下の2つのグループに関係します:

  • 米国政府の請負業者およびベンダー:米国連邦政府機関と取引を行う組織は、ほとんどの場合NIST準拠が求められます。これは、米国政府が請負業者やベンダーに対し、政府資源に影響を与える可能性のあるサイバーリスクの軽減策としてNIST準拠の証明を義務付けているためです。この要件は直接の政府請負業者だけでなく下請け業者にも適用されることに留意してください。つまり、連邦政府請負業者である企業と契約する事業者は、連邦機関に影響を与える活動を行う場合、NIST準拠が必須となります。
  • その他の組織:米国政府機関と(直接・間接を問わず)契約しない事業者にとって、NIST準拠は厳格な要件ではありません。しかしながら、多くの組織はサイバー衛生状態を強化する手段として、自主的にNIST CSFへの準拠を選択しています。これは特に米国企業に顕著であり、NISTは事実上、全米組織が満たすべきサイバーセキュリティ基準と見なされる傾向があるためです(世界の他の地域では、別のサイバーセキュリティ基準であるISO 27001がより一般的に使用される枠組みです)。ただし、NISTの要件は米国に特化したものではなく、あらゆる場所の組織が希望すればNIST準拠を選択できます。

したがって、技術的には米国連邦政府セクターで事業を行う企業のみにNIST CSF準拠が義務付けられていますが、サイバーセキュリティとコンプライアンス対応準備の観点から、自主的にNISTに準拠することはベストプラクティスとなり得ます。また、NIST準拠を積極的に推進することで、将来的に連邦政府の請負業者や下請け業者としての機会が生じた際に、企業がそれらを追求しやすくなります。

NIST準拠の重要性

NIST準拠の基本を説明したところで、サービス・プロバイダ(SP)と一般企業の2つの特定グループにとってNISTが重要な理由をもう少し詳しく見ていきましょう。

SPにとってNISTが重要な理由

SPにとって、NIST CSFに沿った運営は、顧客が評価する高いサイバーセキュリティ基準を設定するのに役立ちます。企業がNIST準拠であることを表明し、実証できる能力は、サイバーセキュリティへの強いコミットメントを示し、競争の激しい市場でSPが差別化を図る助けとなります。

さらに、政府部門での業務を目指すSPにとってNIST準拠は必須要件です。政府機関は通常NIST準拠を要求するため、準拠していないSPが米国連邦政府機関や請負業者にマネージドサービスを提供しようとすれば、ベンダーリスク評価に失敗するでしょう。

NISTが企業とITチームにとって重要な理由

一般企業にとって、NIST準拠を選択することは総合的なコンプライアンス準備に向けた良い一歩です。企業がどの業界で事業を展開しているかにかかわらず、NIST準拠は強固なセキュリティ態勢を確立するのに役立ち、同時に一般データ保護規則(GDPR)やカリフォルニア州消費者プライバシー法(CCPA)などの他のサイバーセキュリティやデータプライバシーの枠組みへの準拠準備も整えます。

NIST CSFへの準拠は、ダウンタイムリスクの最小化と事業継続性の確保にも寄与します。これは、サイバーリスクの予防・検知に役立つ管理策や手順を定義するだけでなく、NISTがシステムのバックアップや効率的な復旧準備に関する規定を含んでいるためです。

NIST準拠のためのセキュリティ管理策

現行版のNISTフレームワークには1,000を超えるセキュリティ管理策(企業が採用すべき具体的な手順や保護策)が含まれています。全ての組織が全ての管理措置を実施する必要はありません。管理措置は、組織が管理すべきリソースの種類やリスクに関連する場合にのみ適用されます。

したがって、個々のNIST管理措置を特定して実施しようとするよりも、NISTの「管理措置ファミリー」に焦点を当てる方が合理的である場合が多いです。管理措置ファミリーとは、管理措置のグループであり、それぞれが異なるリスクカテゴリーや運用領域に関連しています。

現在、NIST管理措置ファミリーは20種類存在します:

  • アクセス制御(AC):システムや情報へのアクセス権限と条件を管理します。
  • 認識と訓練(AT):従業員がセキュリティリスクを認識し、セキュリティ責任を遂行するための訓練を受けることを保証します。
  • 監査と説明責任(AU):システム活動を追跡し、ユーザーの行動に対する説明責任を確保します。
  • 構成管理(CM):セキュリティと完全性を維持するためのシステム設定と変更を管理します。
  • 緊急時対応計画(CP):緊急対応、バックアップ運用、システム復旧の準備を整える。
  • 識別と認証(IA):アクセス許可前にユーザー、デバイス、プロセスの身元を検証する。
  • インシデント対応(IR):サイバーセキュリティインシデントを検知、対応し、復旧する。
  • 保守(MA):システム保守が安全に、かつ権限のある担当者によって実施されることを保証する。
  • メディア保護(MP):機密情報を含むデジタル媒体および物理媒体を保護します。
  • 物理的・環境的保護(PE):システムへの物理的アクセスを保護し、環境的脅威から防御します。
  • 人的セキュリティ(PS):システムへのアクセス権限を持つ個人が適切に審査・管理されることを保証します。
  • 計画(PL):セキュリティ制御の実施と管理に関する方針と計画を策定します。
  • プログラム管理(PM): セキュリティプログラムに対する組織全体の監督とガバナンスを提供する。
  • リスク評価(RA): 組織の運用とシステムに対するリスクを特定し評価する。
  • セキュリティ評価と認可(CA): システムがセキュリティリスクについて評価され、使用が認可されることを保証する。
  • システムおよび通信保護(SC): 転送中および保存中のデータを保護し、システム境界を保護する。
  • システム・情報完全性(SI):システムの欠陥や不正変更を特定、報告、修正する。
  • システム・サービス調達(SA):システム開発および調達ライフサイクル全体を通じてセキュリティが考慮されることを保証する。

NIST制御ファミリおよび個別制御の詳細に関する公式参照資料は、NIST要件を詳細に定義したNIST特別刊行物800-53である。

NISTサイバーセキュリティフレームワーク内のコア機能

セキュリティ制御を定義するだけでなく、NISTはサイバーセキュリティ運用を5つの主要な「機能」に分類しています:識別、保護、検知、対応、復旧。これらの機能はサイバーセキュリティ戦略を導く高レベルのフレームワークと捉え、制御は様々なリスクや脅威を軽減できる具体的な手順です。

以下にNISTの各機能を詳しく見ていきます。

識別

識別機能は、IT資産と関連リスクの評価・査定に焦点を当てます。これには、ITシステムで誰が何を実行できるかを決定するアクセス制御の評価などの実践が含まれます。リスクの優先順位付け、および攻撃者に侵害された場合に組織に最大の危険をもたらす資産の特定も、識別機能の一部です。

保護

保護機能の目的は、組織のネットワーク、クラウド環境、その他のITリソースに影響を与え得る様々なリスクを管理するための適切な保護策を実施することです。効果的なアクセス制御の実施や、従業員トレーニングなどの実践が含まれます。

検知

検知機能は、活動中のリスクと脅威の特定に焦点を当てます。理想的にはサイバーセキュリティ事象が発生しないことが望ましいですが、実際にはすべての潜在リスクを軽減することは不可能です。そのため、事象が拡大する前に検知することは、NISTのサイバーセキュリティアプローチにおけるもう一つの重要なステップです。

対応

サイバーセキュリティ脅威の検知は、組織が効果的に対応できる場合にのみ価値があります。ここで対応機能が役割を果たします。攻撃発生時に組織が攻撃を封じ込め、侵害が完全に収束するまで脅威を修復できる対応計画の策定・実行をカバーします。

復旧

NISTの最終機能である復旧は、サイバー攻撃の影響を受けたシステムの復元を焦点とします。データバックアップや復旧計画の整備など、侵害されたエンドポイント、データベース、その他の資産を最小限のデータ損失で復元するための実践が含まれます。

結論:サイバー衛生の基盤としてのNIST準拠

NISTへの厳格な準拠が義務付けられているSPや企業は少数ですが、NIST CSFの遵守が特に求められていない組織でも、NIST準拠から恩恵を得られるケースは多くあります。そのため、NISTのセキュリティ管理策と機能を理解し、それらに準拠した手順を実装することがベストプラクティスです。

これにより政府関連業務の獲得に有利になる可能性があり、たとえそれが実現しなくとも、組織のセキュリティ強化とコンプライアンス達成につながる。これは決して悪いことではない。

タグ:

アサヒビールの供給網を遮断したサイバー攻撃とは

企業が今一度見直すべきセキュリティ対策について

アサヒグループホールディングスがランサムウェア被害に遭い、全国でアサヒビールの出荷が止まったことが話題になっています。サイバー攻撃を受けてから一週間が経った10月6日現在、一部の業務は手動対応で再開されているようですが、システム障害からの復旧はまだ目途が立っていないと報じられています。

「サイバー攻撃を受けてから一週間」と書きましたが、正確には、サイバー攻撃を受けたことが判明してから一週間です。実際の攻撃をいつ受けたかは、判っていません。

これより前の段階かでシステムへの侵入があり、その侵入経路から徐々にシステム全体を侵食してランサムウェアが実装されたはずです。犯行グループが身代金要求の準備を十分に整えてから一気にシステムを暗号化したのが一週間前だっただけで、犯行にかけた時間は不明ですが、長い場合は半年ほどかけてじっくりシステムを侵略する場合もあると言われています。

アサヒグループホールディングスは、サイバー攻撃を受けたことを正式に発表すると同時に、「情報漏えいの可能性を示す痕跡が確認された」とも公表しているので、身代金の対価は、暗号化の解除だけでなく、機密情報の保持も含まれているのかもしれません。いわゆる二重脅迫(Double Extortion)です。二重脅迫の場合、犯人はシステム侵入後になるべく重要な情報をなるべく多く抜き取る作業をしていたわけで、侵入がしばらく前だった可能性が高まります。

二重脅迫があれば、三重脅迫(Triple Extortion)もあり得るので、状況の深刻化が危惧されます。つまり、盗み出した機密情報の悪用による顧客や提携先への被害拡大をほのめかして、身代金の要求を強める手口です。

報じられているところによると、アサヒグループが攻撃を受けたのは商品受注・出荷システム「SPIRIT」を中心とした基幹システムで、Active Directory(AD)やvCenter/ESXiの仮想化サーバーが暗号化されたと推定されています。

犯人がそこにたどり着く前に、どこから侵入したかは不明ですが、アサヒグループのような、巨大なサプライチェーンを構成する大企業には、そのネットワーク全体のあらゆる箇所に侵入リスクがあると言わざるを得ません。たとえば、あえて極端な例を挙げれば、業務提携先の一社員が自宅でリモートワーク中にちょっと席を離れ、その間に家族が急ぎの調べ物があって、たまたま開いていたノートパソコンで情報検索してヒットした最初のページを開いたら、マルウェアが自動的にダウンロードされたのかもしれません。

実際には、家族がまちがって悪意あるページを開いたり、リンクをクリックしたりしなくても、社員が通常業務の一環として、同僚や上司からのメールに添付された、当然確認すべきドキュメントを開いたり、リンクをクリックしただけかもしれません。

つまりは「フィッシング」ですが、AIを活用したソーシャルエンジニアリングの発達もあって、フィッシングの巧妙さは日に日に洗練されています。現実に、今回のようなサイバー攻撃の侵入を許してしまう最大の原因は、世界的な調査によれば、ここ数年フィッシングが堂々一位の座を守り続けています。

脅威インテリジェンスリサーチの最大手Cisco Talosの最新レポートによると、フィッシングの75%は、一見うたがいようもない社内連絡や提携先からのメールだそうです。社内システムなどへの偽のログインページが本物そっくりに表示され、騙されてパスワードや多要素認証(MFA)トークンを入力してしまうことがサイバー被害の発端になっているとの調査結果があります。

これを防ぐには、社内教育を徹底して、関係者全員のセキュリティ意識を高めることが重要です。個々のデバイスを頻繁にアップデートし、セキュリティ対策ツールを常に最新にしておくことも重要です。もしマルウェアがどこかに潜んでいるのなら、最新のセキュリティ情報にもとづいて早めに芽を摘まなければなりません。

同時に、個々のユーザーのアクセス権を業務上の必要最低限にとどめる「最小権限の原則(Principle of Least Privilege)」や、社内外を問わずすべてのユーザーやデバイスからのネットワーク接続を一切信用せずに逐一検証する「ゼロトラスト」を徹底することも大事になります。

これらは、サイバー攻撃をなるべく受けないようにするための対策ですが、大企業の巨大システムには大勢のスタッフがアクセスしなければならないので、人的ミスを完全に防ぐことはできません。つまりは、サイバー攻撃を受けてしまった場合の、バックアップとリカバリ体制が日頃から万全に整っていることが大前提となります。

アサヒグループでシステム復旧の目途が立っていないと報じられている理由として、バックアップファイルもサイバー攻撃を受けてしまったのではないかとの指摘があります。真偽のほどは定かではありませんが、バックアップファイルは最後の砦なので、バックアップファイル自体が攻撃を受けることは絶対に避けなければなりません。

そのための対策としては、従来よりバックアップの「3-2-1ルール」が推奨されていますが、それをさらに補強したVeeamの提唱する「3-2-1-1-0ルール」を徹底したいところです。簡単に言うと、バックアップデータを3件、2種類のメディアに保存し、うち1件はオフサイトにする「3-2-1ルール」を以下のようにアップグレードしたのが「3-2-1-1-0ルール」です。

  • ルール1:データは3バージョン保管する
  • ルール2:保管には2種類以上のメディアを使用する
  • ルール3:そのうち1つはオフサイトに保管する
  • ルール4:そのうち1つはイミュータブル(変更不可)あるいはオフライン(エアギャップ)にする
  • ルール5:リカバリ プロセスを定期的に検証してエラーを0にする

これを徹底することで、最悪の場合でも、ランサムウェアにバックアップファイルまでもが暗号化されることはなくなり、バックアップファイルからの確実なリカバリが保証されます。

アサヒグループで被害が拡大した理由は、昨年のKadokawaグループのケース同様、システム統一で合理化を進めたDXが裏目に出たのではないかという指摘もあります。両社とも仮想化インフラが暗号化されてしまったのが共通点だそうです。

仮にDXが裏目に出たことが事実だとしても、DXによるシステム統合や仮想化に問題があるのでは決してなく、このDXの取り組みにセキュリティ対策が組み込まれていなかった(あるいは重要度が十分でなかった)ことが問題のはずです。

システム開発のベストプラクティスとして、セキュリティ対策は設計段階から組み込まれていなければならないと言われています。DXも同様で、計画段階からセキュリティ対策を最重要課題に位置付け、セキュリティが決して後付けの付け焼き刃にならないようにしなければなりません。

奇しくも、アサヒグループのサイバー被害は自民党の総裁選とタイミングが重なりました。まもなく高市内閣が発足される見込みですが、高市さんはアベノミクスを継承するサナエノミクスを提唱し、「大胆な危機管理投資」をその重要な要素として掲げていると聞きます。近年は、国家ぐるみの政治的なサイバー攻撃も増えています。日本政府や日本企業がDXを推進するうえでは、サイバーセキュリティを重要な柱に据えるべきでしょう。

クライムが提供するランサムウェア対策ソリューションの特集サイトはこちらをご覧ください。

データ移行計画とは? 主要な手順とベストプラクティス

データ移行とは、情報をあるシステムから別のシステムへ移動させるプロセスです。定義は単純ですが、実行は容易ではありません。準備なしに行われた移行は、ダウンタイムやデータ損失、ITチームへの多大なストレスを招く可能性があります。明確な計画はこれらのリスクを軽減し、データが正しく転送され、ダウンタイムが制御され、常に代替手段が確保されるための枠組みを提供します。

データ移行計画の役割

移行計画では、移行対象、移行方法、最適なツール、結果の検証方法を明示します。単なるチェックリストではなく、異なる手法の比較、テスト移行の実施、本番環境向けの安全な経路の選択を可能にします。計画なしの移行は即興作業に陥りがちで、業務上重要なシステムにとって安全とは言えません。

移行にはいくつかの形態があり、それぞれ固有の課題があります:

  1. ストレージ移行 – 通常、既存のソリューションから新しいストレージソリューションまたは新しいリポジトリへの移行を意味します。ソースからターゲットへの単純なデータコピー、または組み込みのストレージ移行ツールの使用が含まれる場合があります。
  2. データベース移行 – 通常、既存のデータベースを同じデータベースエンジンの新しいバージョン、または別のエンジンに移行することを意味します。
  3. アプリケーション移行 – 通常は既存アプリケーションを異なるシステムやクラウドへ、あるいはクラウドからオンプレミス環境へ移行することを意味します。
  4. クラウド移行 – 企業リソースの全部または一部をクラウドへ移行することを意味します。クロスクラウド移行を含む場合もあります。
  5. 業務プロセス移行 – 既存の業務プロセスやワークフローを異なるプラットフォームへ移行することを意味し、通常は完全または部分的な変革を伴います。

データ移行の種類と並行して、移行の引き金となる要因を理解することが重要です。

データ移行の引き金

移行プロジェクトの引き金も同様に多様です:

  1. インフラ更新 – 最も一般的な移行の引き金です。物理法則上、年を重ねるごとに既存ハードウェアの故障リスクは高まり、メンテナンスに要する時間も増加します。ハードウェアのライフサイクルは通常5~7年であるため、この要因は組織に繰り返し発生します。
  2. 合併・買収 – インフラ更新ほど頻繁ではありませんが、確実に移行の要因となります。名称が示す通り、自組織が買収・合併される場合、あるいは他組織を買収して自社インフラに統合する場合に発生します。状況によってプロセスは異なりますが、このようなケースでは移行がほぼ確実に行われます。
  3. クラウドファースト戦略 – 組織が既にオンプレミスインフラを保有し、クラウドベース環境やSaaSを活用したマイクロサービスアーキテクチャへの移行により設備投資(CapEx)を削減したい場合、一般的なトリガーとなります。これは通常、インフラ更新トリガーの代替手段となります。
  4. コンプライアンスとデータ居住地 – 政府機関や規制対象業種への事業拡大、あるいは政府による新規規制の施行に伴い、データプライバシー等のコンプライアンス対応が必要となった場合、既存インフラの見直しと対応策の検討が求められます。これには移行が伴うことが多々あります。
  5. アプリケーションの近代化 – 組織が異なるソフトウェアへの移行を決定した際に通常トリガーされます。最も一般的なケースは、予算制約や特定機能の必要性から、データとワークフローを維持することを目的とした、あるCRMエンジンから別のCRMエンジンへの移行です。

データ移行計画の重要性

移行を「ただ実行するだけ」のものと扱うのは危険です。計画なしでは、本番データと事業継続性を賭けていることになります。計画は安全策となる:テスト済みのバックアップ、ロールバックオプション、明確なダウンタイム期間、成功を測定する手段を提供する。また技術・業務双方の関係者が移行内容を理解し、予期せぬ事態を減らす。

リスク軽減

計画の最重要要素はリスク軽減である。バックアップは必須だが、必要時にどれだけ迅速に復元できるかを知ることも同様に重要だ。移行計画では、手順の失敗や不整合結果発生時のロールバックを想定すべきである。

事業継続性

事業継続性も重要な考慮事項です。ゼロダウンタイム移行が不可能でも、現実的な復旧時間目標を設定し、影響が最小限となる時間帯に切り替えをスケジュールできます。

データ移行計画の構築

ソースシステムとターゲットシステムの評価

プロセスはソースシステムとターゲットシステムの両方の評価から始まります。これには互換性の確認、利用可能なツールの評価、ダウンタイムやデータ形式の問題などの潜在的な落とし穴の特定が含まれます。

範囲と目的の定義

対象を把握したら、移行の範囲と目的を定義します。移行するデータやシステム、移行の理由、成功の定義を明確にします。

移行戦略の選定

戦略とツールの選択が焦点となります。ベンダー提供の組み込みツールで対応可能な移行もあれば、サードパーティ製ソフトウェアが必要なケースもあります。タイミングも重要です:移行を業務時間内に行うか週末に実施するかによって、プロセスがもたらす混乱の度合いが大きく変わります。

バックアップ

この段階では、バックアップが最新であるだけでなく復元可能であることも確認することが重要です。多くの移行失敗は、事前にバックアップをテストしていれば回避できた可能性があります。

テスト

テストは理論と現実が交わる場です。サンドボックス環境での試行移行により互換性問題が明らかになり、計画の精緻化が図れます。これらのテスト結果を文書化することは極めて重要です。本番移行前に何が成功し、何が失敗し、何を調整すべきか明確な道筋を示すからです。テストフェーズ終了後、得られた知見を反映して計画を更新し、移行完了後に成功を確認する方法を明確にするため、最終的な検証手順を明確に定義すべきです。

検証と最適化

テストフェーズ終了後、得られた知見を反映して計画を更新し、移行完了後に成功を確認する方法を明確にするため、最終的な検証手順を明確に定義すべきです。

データ移行における一般的な課題

移行には常に課題が伴います。プラットフォーム間の連携が必ずしも円滑とは限りません。あらゆるシナリオに対応する適切なツールが存在しない場合もあります。クラウド環境間やクラウド環境内でのデータ移動時には、セキュリティ上の懸念がより深刻化します。時に最大の課題は、単に計画の不備や急ぎすぎたスケジュールであることもあります。これらの問題を完全に排除することは常に可能ではありませんが、入念な準備、反復テスト、関係者との明確なコミュニケーションにより、失敗のリスクを大幅に低減できます。

データ移行を成功させるためのベストプラクティス

移行プロセスで最も時間を要するのは準備段階です。以下に役立つベストプラクティスをいくつか紹介します:

  1. 明確な範囲と目標の定義 – 移行の目標を理解し、明確な範囲を定義することはプロセス全体において重要です。範囲と可能性を把握した上で準備、テスト、実行を行うことで、作業が格段に容易になります。
  2. 事前のデータクレンジングと検証 – 企業データには不要データ、重複データ、非アクティブデータが大量に存在するケースが一般的です。移行前にこれらをアーカイブ化し、プロセスを長引かせず、重要かつ頻繁に利用されるデータに集中しましょう。
  3. 移行テストの実施 – 適切なテストを完了する前に移行を実行しないでください。テスト期間の延長を躊躇しないでください。移行が失敗した理由を探すよりも、移行を確実に成功させる方が重要です。
  4. ビジネスと技術の両ステークホルダーを巻き込む – 主要なステークホルダーを積極的に巻き込みましょう。最終的に移行後のシステムの最大の受益者は彼らです。双方が共通言語で対話できるようにします。技術的な問題をビジネスステークホルダーと議論したり、その逆を行ったりすることは逆効果です。
  5. 各フェーズを文書化する – 文書化により、既に試した内容や失敗した箇所を追跡でき、将来の移行に向けたプロセスを確立できます。
  6. 移行後のデータ検証 – 最高クラスの移行ツールを使用した場合でも、この検証は不可欠です。移行後のデータ破損や不整合の可能性は常に存在します。移行前後のハッシュ値や特定カウンターの比較などのチェックを実施することで、データの正常な移行を確認できます。また、移行前には常に最新のバックアップを確保してください。これにより、トラブルシューティングや復旧作業に費やす膨大な時間を節約できます。

結論

移行の成功は、ツールそのものよりも準備と計画に大きく依存します。体系的なアプローチ、繰り返しテスト、慎重な検証により、データの安全な移動、許容範囲内のダウンタイム維持、ビジネスの継続的な稼働が保証されます。適切な計画を立てれば、移行は賭け事ではなく、予測可能で管理可能なプロセスとなります。

クライムはデータ移行要件にどう貢献できるか?

クライムでは各種移行ツール、サービスを国内で提供しています。

タグ: , , , , , ,

AWS S3オブジェクトロックでデータの安全性を確保する手法

テープストレージの全機能を備えつつ、物理的なテープを排除

過去のIT部門は「書き込み一回、読み取り複数回」機能(WORM)を提供するテープバックアップに依存していた。ヴァン・ホイエが指摘するようにテープには多くの欠点があるにもかかわらず、一部企業はテープに戻りつつあります。

では、セキュリティ意識の高いITリーダーは、他のシステムからエアギャップされ、遠隔ハッキングから安全な現代的なWORMシステムをどう構築すべきか?

必要なのは、不変性をサポートするAWS互換のS3ストレージだけです。技術的には、コンプライアンスモードのAmazon S3 Object Lockを指します」

S3 Object Lockとは何か、その重要性

AWSのAPIを使用すれば、書き込み一回・読み取り複数回(WORM)モデルでオブジェクトを保存できます。これにより、一定期間または無期限にオブジェクトの削除や上書きを防止できます。オブジェクトロックは、WORMストレージを要求する規制要件への対応や、オブジェクトの変更・削除に対する追加の保護層として役立ちます。

S3互換オブジェクトストレージの典型的な企業利用例はバックアップ先です。バックアップファイルはランサムウェアの主要標的であり、最近の攻撃では稼働中のボリューム上のライブデータだけでなくバックアップもロックされます。これにより被害者は身代金を支払わなければ事業を再開する手段を完全に失います。これはあまりにも実際に頻繁に発生しています。

データのロック方法

Object Lockを効果的に使用するには、いくつかの条件を満たす必要があります。バケット作成時にObject Lockフラグを設定し、そのバケットでバージョン管理を有効化する必要があります。さらに、Object Lockフラグが設定されたバケットに対してPUT Object Lock Configuration APIを使用してロック設定を書き込むには、そのバケットでObject Lockを有効化しておく必要があります。

残念ながら、AWS S3仕様では既存バケットへのオブジェクトロック設定方法がありません。既存バケットでオブジェクトロックフラグを有効化するため、Scalityは近日リリース予定のツールを開発中です。

オブジェクトのロック制御方法

オブジェクトをロックするには? S3ではオブジェクトのロック設定を複数方法で提供しています。ガバナンスモードやコンプライアンスモードなどの保持モードでは、設定された期間が満了するまでオブジェクトのロックが保持されます。

ガバナンスモードでは、特定のユーザーにロック設定を上書きする権限を委任できます。ルートアカウントまたはs3:BypassGovernanceRetention権限を持つユーザーのみが、x-amz-bypass-governance-retention:trueヘッダー付きで削除リクエストを送信し、ロックを無効化してオブジェクトを削除できます。これは、ランサムウェア攻撃によるバックアップファイルの誤削除を防ぐのに有用です。ガバナンスモードは、コンプライアンスモードの保持期間設定を作成する前に、保持期間設定をテストするためにも使用されます。

コンプライアンスモードを使用してオブジェクトにロックが設定されると、保持期間が満了するまで、どのユーザーもオブジェクトのバージョンを削除できません。これにはアカウント内のルートユーザー(アカウント認証情報)も含まれます。設定を上書きしたりバージョンを削除したりする権限を他のユーザーに付与することはできません。

保持期間(オブジェクトが削除から保護される期間)はバケットレベルで設定可能であり、設定適用後にそのバケットに配置される全オブジェクトのデフォルトとして機能します。

バケットに設定されたデフォルトの保持期間は、ヘッダー x-amz-object-lock-retain-until-date を使用して日付と時刻を設定することで、オブジェクトレベルで上書きできます。

  • Buckets – 保留期間は日数または年数で設定可能ですが、両方を同時に設定することはできません。
  • Objects – 保留期間はオブジェクトの有効期限となる日時として設定できます。

Legal hold(法的保持)もオブジェクトのバージョンに対して有効化できます。法的保持が有効化されると、オブジェクトの保留日や保留モードにかかわらず、法的保持が解除されるまでそのオブジェクトバージョンは削除できません。

オブジェクトのバージョンに対してリーガルホールドを設定するには、PUTオブジェクトリクエスト時にx-amz-object-lock-legal-holdヘッダーを設定するか、PUTオブジェクトリーガルホールドAPIリクエストを使用します。アカウント認証情報を持つルートユーザー、またはs3:PutObjectLegalHold権限が付与されたIAMユーザーは、オブジェクトのバージョンに対してリーガルホールドを設定できます。

S3オブジェクトロックに関連するAPI

  • Put Bucket – バケット作成APIを拡張し、バケットへのオブジェクトロック有効化設定を含めることができます。注記: オブジェクトロックが有効化されたバケットでは、Put Bucketリクエストの一環としてバージョン管理が自動的に有効化されます
  • Put Object – オブジェクト配置 API を拡張し、x-amz-object-lock-mode、x-amz-object-lock-retain-until-date、x-amz-object-lock-legal-hold ヘッダーを解析して設定をオブジェクトに保存します。
  • Copy Object – API を拡張し、オブジェクト配置リクエストと同様のロック設定ヘッダーを受け入れます。
  • Create Multipart Upload  – APIを拡張し、PUTオブジェクトリクエストと同様のロック設定ヘッダーを受け付ける
  • Put Object Lock Configuration  – バケットに保存されるオブジェクトのデフォルトロック設定を許可します。このリクエストはオブジェクトロックが有効なバケットでのみ受け入れられます
  • Get Object Lock Configuration – バケットメタデータに設定されたオブジェクトロック設定を取得します
  • Put Object Retention  – オブジェクトバージョンに保持モード/期間設定を設定します
  • Get Object Retention – オブジェクトバージョンに設定された保持モード/期間設定を取得
  • Put Object Legal Hold  – オブジェクトバージョンに法的保持設定を設定
  • Get Object Legal Hold – オブジェクトバージョンの法的保持ステータスを取得

データのプライバシー保護、セキュリティ確保、バックアップは最終的に各自の責任です。世界がより繋がり、サイバー犯罪が高度化する中、御社のデータが影響を受けるのは時間の問題です。重要データにオブジェクトロックを活用することは、リスク低減のための追加手段となります。

タグ: , ,

医療機関におけるサイバーセキュリティの羅針盤:厚生労働省「医療情報システム安全管理ガイドライン第6.0版」徹底解説

はじめに:医療情報セキュリティの重要性と本報告書の目的

医療機関が取り扱う患者の診療情報や健康データは、氏名や病歴などを含む「要配慮個人情報」であり、その機密性と社会的価値は極めて高いものとして認識されています。この情報は、患者の生命と健康を支える医療行為の基盤であると同時に、ひとたび漏洩や改ざんが発生すれば、患者のプライバシー侵害、診療停止、そして医療機関の社会的信用の失墜といった深刻な事態を招く可能性があります。近年、医療機関を標的としたサイバー攻撃は増加の一途をたどり、その被害は、単一の組織に留まらず、地域医療全体に影響を及ぼすほど深刻化しています。

このような背景のもと、厚生労働省は「医療情報システムの安全管理に関するガイドライン」を定期的に見直し、時代の変化に対応するセキュリティ対策の指針を示しています。本報告書は、2023年5月に改定された最新版「第6.0版」を羅針盤として、その多層的な要件、改定を駆動した背景、そして医療現場が直面する現実的な課題を網羅的に分析します。単なる情報提供に留まらず、ガイドラインが求める対策を「コスト」ではなく「事業継続と質の高い医療提供のための戦略的投資」として捉えるための、実践的な知見と提言を提供することを目的とします。

第1章:ガイドライン改定の背景と全体像

1.1. ガイドラインの定義と法的・制度的位置づけ

「医療情報システムの安全管理に関するガイドライン」は、厚生労働省、総務省、経済産業省の3省が連携して策定した指針であり、医療情報を取り扱うすべての組織が遵守すべき安全管理の基準を定めています。その目的は、医療情報の漏洩や不正アクセスから患者の個人情報を守り、デジタル化された医療情報の安全な運用を確立することにあります。

今回のガイドライン改定は、関連法制度の変更と密接に連動しています。2023年3月に医療法施行規則が改正され、病院や診療所などの管理者は、医療の提供に著しい支障を及ぼすおそれがないように、サイバーセキュリティを確保するために必要な措置を講じることが義務化されました。これにより、ガイドラインの要件は法的拘束力を伴うものとなり、その遵守はもはや任意ではなく不可欠なものとなっています。さらに、令和6年度の診療報酬改定では、電子カルテの保全のためのサイバーセキュリティ体制が、診療録管理体制加算として評価される仕組みが導入されました。これは、セキュリティ対策を単なる義務に終わらせず、体制を整備している医療機関を経済的に評価する制度的インセンティブを付与するものです。

1.2. 第6.0版への改定を駆動した3つの主要要因

「ガイドライン第6.0版」への改定は、医療ITを取り巻く環境の劇的な変化に対応するための、本質的な見直しです。改定を駆動した主要な要因は、主に以下の3点に集約されます。

  • 要因①:サイバー攻撃の巧妙化と深刻な被害近年、医療機関を標的としたランサムウェア攻撃が増加しており、電子カルテシステムが使用不能となり、長期間にわたる診療停止を余儀なくされる事例が相次いでいます。これらの攻撃は、単一の医療機関だけでなく、地域医療全体に影響を及ぼすほど深刻です。特筆すべきは、大阪府の大規模病院への攻撃事例です。このインシデントでは、外部の給食サービス事業者のシステムが侵入経路となり、病院本体に被害が波及したことが判明しました。この事態は、自院のセキュリティ対策だけでなく、関連事業者を含むサプライチェーン全体のセキュリティが不可欠であることを明確に示しました。
  • 要因②:オンライン資格確認の義務化とネットワークの拡張2023年4月より、オンライン資格確認システムの導入が原則として義務化されました。これにより、多くの医療機関のネットワークが外部と恒常的に接続されるようになり、新たなサイバーリスクへの対応が急務となりました。ガイドラインは、この新たなネットワーク接続を前提としたセキュリティ対策を盛り込んでいます。
  • 要因③:クラウドサービスの普及と「3省2ガイドライン」への統合低コストで高効率な運用が可能なクラウドサービスの普及により、医療情報システムを外部事業者に委託するケースが増加しています。従来の3省4ガイドラインは、事業者にとって準拠の負担が大きかったため、総務省・経済産業省のガイドラインが統合され、現在は「3省2ガイドライン」として整理されています。これにより、医療機関とサービス提供事業者の間で、責任の所在を明確化することが強く求められるようになりました。

1.3. 考察:ガイドラインは「コスト」から「投資」へと変貌した

これまでのガイドラインは「推奨」の色彩が強く、多くの医療機関がセキュリティ対策を後回しにする傾向がありました。しかし、相次ぐ大規模なサイバー攻撃が診療継続性への深刻な脅威であることを明らかにしたことで、国は、法的義務と経済的インセンティブという二重の梃子を導入しました。医療法施行規則の改正は、サイバーセキュリティを医療機関の管理者にとっての法的義務とし、診療報酬改定は対策への取り組みを評価対象としました。

この一連の流れは、セキュリティ対策が「あればよいもの」から「なければ経営が成り立たない」必須のインフラへとパラダイムシフトしたことを示唆しています。ガイドラインが「質の高い医療の提供や個人の健康の維持増進の前提」とまで表現されているのは、この変化を端的に示していると言えます。もはやセキュリティ対策は単なるコストではなく、医療機関の事業継続性を確保し、社会的信頼を獲得するための戦略的投資へと変貌したのです。

表1-1:医療情報システム安全管理ガイドライン改定の動因と要点

動因関連要因と社会的・技術的変化改定の要点
サイバー攻撃の深刻化ランサムウェアの多発、サプライチェーン攻撃の顕在化、IoT技術の普及と脆弱性増加ゼロトラストの考え方導入、BCP策定の重視、サプライチェーン全体の安全管理要求
オンライン資格確認の義務化ネットワークの常時外部接続化、外部からのアクセスポイント増加ネットワーク関連のセキュリティ対策の強化、ゼロトラスト思考の導入
クラウドサービスの普及低コスト・高効率な外部サービスの利用増加、提供事業者の多様化「3省2ガイドライン」への統合、医療機関と事業者の責任分界の明確化

第2章:ガイドラインが要求する安全管理措置の詳解

「ガイドライン第6.0版」は、医療情報システムに対する安全管理策を「組織的」「物理的」「技術的」の3つの側面から体系的に要求しています。これらの対策は、相互に補完し合い、包括的な防御体制を構築することを目的としています。

2.1. 組織的安全管理策:セキュリティ文化の醸成と体制の構築

組織的安全管理策は、セキュリティ対策の基盤を築くための人的・制度的な側面を網羅します。この柱が求めるのは、単に技術を導入することではなく、組織全体としてセキュリティを重視する文化を醸成することです。

  • 方針策定と責任の明確化組織としての情報セキュリティ方針と個人情報保護方針を策定・運用することが求められます。また、経営者、企画管理者、運用担当者など、各階層における責任と権限を明確にし、誰がどの範囲のセキュリティに責任を持つのかを定める必要があります。これにより、セキュリティ対策が特定の担当者だけに任されることなく、組織全体で取り組むべき経営課題として位置づけられます。
  • 職員へのセキュリティ教育と訓練人的なミスがサイバー攻撃の主要な侵入経路となることから、職員への定期的なセキュリティ教育とシミュレーション訓練の実施が義務付けられています。具体的には、不審なメールの取り扱い方や、パスワード管理の重要性などを周知徹底することが求められます。この教育は、技術的対策を運用するための「人」と「プロセス」を強化し、セキュリティを組織の文化として定着させる上で不可欠な要素です。
  • インシデント対応計画(BCP)の策定サイバー攻撃を完全に防ぐことは不可能であるという前提に立ち、被害を最小化し、迅速に復旧するためのインシデント対応計画(BCP)を策定することが強く要求されています。この計画には、インシデント発生時に組織内および外部の関係機関(事業者、厚生労働省、警察など)へ連絡するための体制図を含める必要があります。また、診療を継続するために必要な情報や、データ・システムのバックアップと復旧手順を事前に確認しておくことも重要です。これは、セキュリティ対策を「予防」だけでなく「レジリエンス(回復力)」の観点から捉え、事業継続性を確保しようとする思想の表れです。

2.2. 物理的安全管理策:情報資産への物理的アクセス制御

物理的安全管理策は、情報資産への物理的なアクセスを制限し、盗難や災害から保護するための対策です。

  • 施設管理と物理的防護サーバー室など、医療情報システムが設置されているエリアへのアクセスを制限し、施錠や監視カメラの設置といった物理的な防護を行うことが求められます。これは、許可された者以外が機器に直接接触し、不正な操作や情報の持ち出しを行うことを防ぐための基本的な措置です。
  • バックアップ管理と耐災害性の確保データの定期的なバックアップと、その保管場所の適切な管理が必須です。ガイドラインでは、バックアップデータを「不正ソフトウェアの混入による影響が波及しない手段」で管理することが示唆されています。これは、ネットワークに常時接続されたバックアップ先もランサムウェアの標的となることを想定し、サイバー攻撃や自然災害などから独立してデータを保護する必要性を示しています。この考え方は、IT業界で広く知られる「3-2-1ルール」(3つのコピー、2つの異なる媒体、1つはオフサイト)に通じるものであり、物理的対策がサイバーレジリエンスの最後の砦であることを示しています。
  • 記録媒体の適切な廃棄医療情報が保存された記録媒体(ハードディスク、USBメモリなど)を、高温による融解や裁断といった物理的破壊措置を講じるなど、安全に廃棄する手順を確立することが求められます。これにより、記録媒体の紛失や盗難による情報漏洩リスクを未然に防ぎます。

2.3. 技術的安全管理策:サイバー脅威への直接的防御

技術的安全管理策は、情報システム自体に実装されるセキュリティ機能に関する要求事項です.

  • アクセス管理と多要素認証医療情報システムへのアクセス権を適切に管理し、利用者認証や権限設定を徹底することが求められます。特に、IDとパスワード以外の認証方法を組み合わせる「多要素認証」の導入が推奨されています。これは、従来の認証方法が総当たり攻撃や情報漏洩によって容易に突破されるという現実を踏まえ、セキュリティ強度を飛躍的に向上させるための要件です。パスワード要件についても「英数字、記号を混在させた8文字以上の文字列」が望ましく、より強固な対策として「13文字以上」を推奨する項目も存在します。多要素認証の導入は、複雑なパスワードを定期的に変更する煩雑さを緩和し、より実用的で強固なセキュリティ対策へと誘導する意図が見て取れます。
  • 脆弱性対応システムやソフトウェアの脆弱性を定期的に点検し、セキュリティパッチや最新ファームウェアを迅速に適用することが求められます。医療機関へのサイバー攻撃では、VPN装置など外部に接続する機器の脆弱性が突かれる事例が多数報告されており、迅速な脆弱性対応の重要性が強調されています。
  • 監視とログ管理システムログを記録し、そのレビューに基づく監視体制を確立することが要求されています。これにより、不正なアクセスやサイバー攻撃の兆候を早期に発見し、被害拡大を食い止めることが可能となります。

表2-1:ガイドライン第6.0版が求める安全管理策要件一覧

分類要件具体的な要求事項(抜粋)
組織的セキュリティ方針の策定情報セキュリティ方針、個人情報保護方針の設定・運用
責任と権限の明確化経営者、企画管理者、運用担当者の責任範囲を明確化
教育と訓練職員に対し、定期的なセキュリティ教育や訓練を実施
インシデント対応計画インシデント発生時の連絡体制整備、BCPの策定
物理的施設管理サーバー室へのアクセス制限、施錠、監視カメラの設置
バックアップ管理定期的なデータバックアップと耐災害性の確保
記録媒体の廃棄物理的破壊を含む安全な廃棄手順の確立
技術的アクセス管理アクセス権管理、利用者認証・権限設定の徹底、多要素認証の導入推奨
脆弱性対応システムやソフトウェアの脆弱性を定期的に点検・更新
監視とログ管理システムログの記録とレビューに基づく監視体制の確立
通信の暗号化ネットワーク通信や保存データの暗号化

第3章:新たな概念の導入と責任分界の明確化

現代の医療IT環境の複雑化に対応するため、ガイドライン第6.0版は、従来のセキュリティ思想からの脱却と、関係者間の役割・責任の明確化を強く求めています。

3.1. ゼロトラストネットワークの考え方と導入背景

従来のセキュリティモデルは、病院ネットワークの「内側」は信頼できるという前提に立ち、外部からの脅威を防ぐ「境界防御」に依存していました。しかし、リモートワークやクラウド利用の拡大によりこの境界が曖昧になり、ひとたび内部に侵入された場合に、被害が容易に拡大するという弱点が露呈しました。

そこで注目されているのが「ゼロトラスト」の考え方です。ゼロトラストとは、「何も信頼しない」を前提に、ネットワークの場所を問わず、すべてのユーザー、デバイス、アプリケーションへのアクセスを常に検証するセキュリティ思想です。これは、一度の認証で安全が保障されるという従来の考え方を根本から覆すものです。ガイドラインでは、このゼロトラスト思考を境界防御型と組み合わせて対応することを推奨しています。これにより、外部からの安全なアクセス(オンライン診療、リモートメンテナンスなど)を確保しつつ、院内ネットワークにおけるランサムウェアの水平展開を防ぐことが可能となります。

3.2. 外部委託・クラウドサービス利用時の責任分界

クラウドサービスの普及により、医療情報システムの管理責任は、医療機関だけでなく外部のサービス事業者にも分散するようになりました。この状況に対応するため、ガイドラインは、外部委託・外部サービスを利用する場合に、医療機関と事業者の間で「責任の所在」を明確化することを強く求めています。

特に、SaaS、PaaS、IaaSといった多層的なサービス提供モデルにおいては、各事業者と医療機関の責任範囲が異なります。ガイドラインは、このクラウドサービスの特徴を踏まえた「責任分界の考え方」を整理し、双方の役割と義務を明確にすることを要求しています。また、事業者は、提供するシステムのリスクアセスメントを実施し、その結果について医療機関とリスクコミュニケーションをとる必要があるとされています。このプロセスは、医療機関がベンダーを選定し、適切な契約を結ぶ上で不可欠なものとなります。

ゼロトラストと責任分界の明確化は、現代の分散化した医療IT環境において、セキュリティを確保するための車の両輪と言えます。ゼロトラストが技術的な側面から「誰も信頼しない」という思想を導入する一方で、責任分界は、管理責任が外部に分散する現実に対応するための組織的・法的枠組みを提供しています。

表3-1:クラウドサービス利用時における責任分界マトリクス

責任範囲サービスモデル
医療機関の責任SaaS (ソフトウェア)PaaS (プラットフォーム)
データ管理
アクセス権限管理
事業者の責任SaaS (ソフトウェア)PaaS (プラットフォーム)
アプリケーション開発・管理
OSのパッチ適用
物理的セキュリティ

※ IaaS(インフラ)の責任範囲はPaaSと同様。実際には契約内容により変動。

第4章:医療現場の課題と具体的な対策

医療機関がガイドライン遵守に向けて取り組む上で、いくつかの現実的な課題に直面しています。過去のサイバー攻撃事例を分析すると、その原因は技術的脆弱性だけでなく、人的なミスや管理体制の不備に集約されることが明らかになっています。

4.1. 医療機関におけるサイバー攻撃の現状と事例

  • VPNの脆弱性: 徳島県の病院の事例では、VPN装置の脆弱性が攻撃の起点となった可能性が高いとされています。
  • ずさんなパスワード管理: 岡山県の医療機関の事例では、推測しやすいパスワードの使い回しや管理者権限の安易な付与が原因とされました。
  • フィッシングメール: 職員の不注意による不審なメールの開封が、マルウェア感染のきっかけとなる典型的な経路です。

4.2. ガイドライン導入における課題と推奨される対応

  • 課題①:レガシーシステムとIoT機器の脆弱性多くの医療機関は、古いワークステーションやパッチが適用されていない医療機器などのレガシーシステムに依存しており、これらが攻撃の足がかりとなっています。
  • 課題②:予算と人材の不足セキュリティ対策は、多くの医療機関にとって「コスト」と認識され、専門的なIT知識を持つ人材が慢性的に不足しているという現実があります。
  • 課題③:罰則規定の欠如ガイドライン自体には直接的な罰則規定がないため、対策への取り組みが進まないという現実的な課題が存在します。

これらの課題を克服するためには、以下の実践的な対応が推奨されます。

  • チェックリストの活用: 厚生労働省が提供する「医療機関等におけるサイバーセキュリティ対策チェックリスト」を活用し、自組織の現状を可視化・自己評価することが有効です。これにより、「何から手をつければよいか分からない」という課題を克服し、具体的な行動計画を立てることが可能になります。
  • 外部ベンダーとの連携: 自院での対応が難しい項目は、ガイドラインに精通した専門知識を持つベンダーと協力し、脆弱性診断やセキュリティサービスの導入を検討することが推奨されます。
  • 教育支援の活用: 厚生労働省が提供する教育支援ポータルサイト「MIST」を活用し、経営層から現場職員まで、各階層に応じたセキュリティ教育を実施することで、組織全体のセキュリティ意識を高めることができます.

表4-1:医療機関におけるサイバー攻撃被害事例と対応策

被害事例攻撃原因(技術的・組織的側面)ガイドラインが示す有効な対策
徳島県病院VPN装置の脆弱性未対応脆弱性対応(定期的な点検・パッチ適用)、通信制御の確認
岡山県医療機関推測しやすいパスワード、権限管理の不備アクセス管理、多要素認証の導入、不要アカウントの削除
大阪府病院外部事業者システムの脆弱性外部委託・サプライチェーン全体の安全管理、責任分界の明確化
全般的被害職員の不注意によるメール開封職員へのセキュリティ教育と訓練、メール確認時の注意喚起

第5章:結論と将来展望

5.1. 医療情報セキュリティ市場の今後の動向

世界のヘルスケアサイバーセキュリティ市場は、2025年から2032年にかけて年平均成長率18.8%で拡大し、7504億米ドルに達すると予測されています。この市場成長は、脅威の増大だけでなく、医療機関がセキュリティ対策への投資を拡大している事実を反映しています。特に、クラウドベースのセキュリティ技術が市場成長を牽引しており、生成AIは異常検知や脅威分析に活用され始めています。

5.2. デジタルヘルス時代のセキュリティ投資の意義

セキュリティ対策は、もはや単なるITコストではありません。強固なセキュリティ体制は、患者の個人情報を守り、安心してデジタルヘルスサービスを利用できる環境を提供することで、患者からの信頼を獲得する上で不可欠な要素となります。また、安全なオンライン診療やPHR(Personal Health Record)サービスを提供するための基盤となり、医療機関の新たな収益源やブランド価値向上に貢献します。民間PHR事業者が扱う健診情報についても、個人情報保護法に基づく安全管理措置が求められており、相互運用性の確保も課題となっています。これらの取り組みは、医療機関の持続可能性と競争力を左右する戦略的課題であり、セキュリティ投資は「守り」のコストから「攻め」の投資へとその位置づけを変えつつあります。

5.3. 提言:医療機関が取るべき次のステップ

ガイドライン第6.0版の要求を遵守することは、単なるコンプライアンスではなく、患者の信頼と事業の継続性を確保するための戦略的な一歩です。以下に、医療機関が取るべき次のステップを提言します。

  1. 経営層のコミットメント: セキュリティを「ITコスト」から「事業継続のための投資」へと意識を改革し、予算と人的リソースを戦略的に確保する。
  2. 現状把握と段階的導入: 厚生労働省が提供するチェックリストや外部評価(ISMS、プライバシーマーク等)を活用し、自院のセキュリティ体制の現状を正確に把握する。
  3. ベンダーとの戦略的提携: 自院で不足する専門知識を補うため、ガイドラインに精通したベンダーと長期的なパートナーシップを築く。
  4. サプライチェーン全体の最適化: 外部委託先との間で責任分界を明確化し、定期的なセキュリティ評価を実施する。
  5. 継続的な改善サイクル: セキュリティ教育と訓練を定期的に行い、PDCAサイクルを回すことで、組織全体の防御力を継続的に向上させる。

結論として、厚生労働省のガイドラインは、現代の医療IT環境が直面する複雑な課題に対応するための羅針盤です。その要件を遵守することは、患者の信頼を維持し、医療機関の未来を拓くための不可欠な要素となるでしょう。

クライムが提供するランサムウェア対策ソリューションの特集サイトはこちら

タグ: , , ,