コラム

SEのためのストレージ講座

第18回 コンプライアンスへの対応 その2

更新

IT基盤のストレージの役割や課題から仮想化・統合化まで、CTCのエンジニアが解説します

著:クロスファンクショングループ プロダクトマーケティング室
インフラソリューション推進部 菅 博

 今回はデータの改竄防止とDRの概要を説明します。DRは日本語に訳される場合には「災害対策」や「災害復旧」とされる場合が多いようですが、このことからもわかるようにDRとはデータの復元だけでなくサービス再開までを含む非常に大きな概念です。ただし、基本となるデータセットはその中でも最も重要なため、データの遠隔複製そのものを狭義の意味でDRと呼ぶ事があります。

データの改竄防止

 データの不正アクセスやアクセスログを残すだけでなく、そもそも改竄処理を不可能にすることによって、一歩踏み込んだセキュリティレベルを構築することができます。実際、正当な権限のある管理者であっても、オペレーションミスによってファイルを削除したり上書きしたりすることがあることを考えると、ファイルの更新や削除をシステムで防ぐことが求められます。

 また、単純にファイルの上書きを防ぐ目的とは別に、電子データの場合にはデータの真偽性やデータの原本性を問われる事が多く、作為的に中身や日付が更新されたものではないことを証明しなければなりません。例えば、電子メールの内容や送受信のログなどが証拠として受け入れられるには、それらが作成されてから適切な時期に更新不可能な状態に移行していることが求められます。

 改竄や変更を防ぎたいデータとしては電子メールの他に取引情報や種々のシステムログ、会社のIR情報や過去の開発データなどがこれに相当するかもしれません。システム上でデータ更新不可、読み出しのみ可能にする仕組みはWORM (Write Once Read Many) と呼ばれます。WORMを実現する方法はいくつかありますが、現在では著名なストレージベンダーは自社のストレージの機能の一部として(もしくは、WORM専用アプライアンスとして)提供しています。

データの遠隔複製(DR)

図1

 なくなってしまったデータを復元するためにバックアップは必須ですが、あるケースではそれでも不十分な場合があります。バックアップをスナップショットやクローンで作成した場合には、バックアップデータは同じストレージ筺体内に存在しています。そのため、地震や火災などによりストレージそのものが損壊した場合には、オリジナルのデータもバックアップデータも同時に消失してしまい、それを復旧する方法がありません。そのために、ディザスタ・リカバリ(DR; Disaster Recovery)という概念があります。

 業種を問わず、サービスや業務のほとんどがIT化されている企業にとって、データが完全に消失するという事態は会社の存続に影響するため、多くの企業はこうした場合でもデータが復元できるような仕組みを備える傾向にあります。古くからよく行われている方法は、バックアップデータをテープに作成して、テープをまったく安全な場所に外部保管するというものです。しかし、この方法では次のような問題点があります。

  • テープ搬送の費用がかかる
  • テープの管理が煩雑になる
  • バックアップなので、データが戻せる状態は24時間以前の状態でしかない
  • テープからデータをリストアするのに時間がかかる
  • そもそも、データをテープにバックアップするのに時間がかかりすぎる

 しばらく前まではテープ保管が唯一のDR手段でしたが、上記の欠点をクリアするためにオンラインで遠隔地にデータの複製を行う技術が発達してきました。広義の意味ではテープの搬送と保管もDRの範疇には入りますが、現在ではDRといえばオンラインでのデータ複製を指すこと多いようです。ここでは、DRについて最低限度必要な技術用語と考え方を説明しておきます。

RPOとRTO

 DRの仕組みを実装する場合、遠隔地にはデータのコピー先となるシステムが必要であり、オンラインでコピーを行うための回線費用がかかります。従って、DRシステムは一般的に非常にコストがかかるため、データの重要度とサービスの重要度に応じて実装方法が決定されるべきです。この2つの視点を定量的な基準として定めたのがRPO(Recovery Point of Object)とRTO(Recovery Time of Object)という用語です。

図2

 RPOは、障害が発生した場合にどの時点までのデータが復旧可能なのかという指標です。もちろん、障害発生の直前の状態までリカバリできるのが最善ですが、これには相応のコストがかかりサービスの品質にも影響してきます。本当に障害直前の全てのデータセットが必要となるサービスなのか、それとも数時間や一週間前までの状態に戻せればいいのかは、システム実装費に大きく影響してきます。

 RTOは、障害が発生してからサービスが再開されるまでに、どのぐらいの時間を要するかという指標です。もちろん短いに越したことはありませんが、全く別なサイトで全く同様のサービスを即時に再開するには、H/Wも含めて現状システムと同一の構成を遠隔地に必要とするためにやはり費用はかなりかかります。システムだけの問題ではなく、システムを設置する場所の費用やそれらを管理運用していく人員も必要となるため、RTOにおいてもどこまで妥協できるのかを、サービスとデータの重要度に応じて見極める必要があります。

コラム一覧のページに戻り、続きをお読み下さい。

  • このページについてツイッターでツイート(新しいウィンドウで開く)
  • このページをフェイスブックでシェア(新しいウィンドウで開く)

このコラムに関するお問い合わせはこちら

※記載内容は掲載当時のものであり、変更されている場合がございます。