BYOK（Bring your own key）て何でしょうか？

投稿日: 2022年2月14日 クライム
クラウド・仮想インフラ セキュリティ

BYOK（Bring your own key）は、パブリッククラウドのユーザがデータの安全性を保つためにクラウドで使用される暗号鍵を管理できるようにするために、当初EntrustとMicrosoftによって開拓された革新的な概念です。パブリッククラウドサービスの採用が爆発的に増加したため、現在では主要なクラウドサービスすべてでBYOKがサポートされています。BYOKを使用すると、パブリッククラウド・ユーザは高品質のマスターキーをオンプレミスで生成し、そのキーをクラウドサービスプロバイダー（CSP）に安全に転送して、マルチクラウド展開でデータを保護することができます。高品質の鍵を生成および管理するために、BYOKはFIPSおよびコモンクライテリア認証のハードウェア・セキュリティ・モジュール（HSM）を使用し、クラウド・ユーザはこれをオンプレミスで維持するか、サービスとしてリースします。Entrustは、BYOKをサポートするためにnShield HSMとnShield as a Serviceを提供しています。

https://www.climb.co.jp/soft/hytrust/

BYOKは、企業がクラウド移行を達成することできるようにします。

●柔軟性、利便性、費用対効果
●機密データおよびアプリケーションの強力な管理
●クラウド上の鍵の使用状況を完全に把握することが可能
●最高レベルのデータセキュリティ、インテグリティ、信頼性

BYOKの役割は何か？
BYOKは、パブリッククラウドサービスの利用者が、自身の環境で暗号鍵を生成し、その鍵のコントロールを維持しながら、必要に応じて選択したクラウドで使用できるようにする機能を提供します。

BYOKの仕組みは？
CSPは、堅牢な暗号化を用いて、クラウド上の顧客のデータを保護します。データを暗号化する暗号鍵（テナント鍵）が、クラウドストレージのセキュリティを支えているのです。BYOKを使用してクラウド・ユーザが生成したマスターキーは、実質的にCSPのデータ・センター内にテナント・キーを保護するためのロック・ボックスを作成します。これにより、クラウド・ユーザはテナント鍵を管理し、許可された目的のみに使用できるようになり、最終的にクラウド上のデータのセキュリティが保護されます。

BYOKをサポートしているCSPの例は？
Amazon Web Services (AWS)、Google Compute Engine、Microsoft Azure、Salesforceなどの主要なCSPはすべて、Entrustの高保証クラウド統合オプションパックソリューションで実現されるBYOKをサポートしています。

BYOKとHYOK（Hold Your Own Key）はどう違うのか？
Hold Your Own Key (HYOK) は、Entrust HSMS を使用してクラウド・ユーザの最も重要なデータを独自のセキュリティ境界で管理するために Microsoft が提供するオプションです。マイクロソフトはHYOKに代わり、Entrustがサポートする新しいソリューションであるDouble Key Encryption（DKE）を採用し、クラウド・ユーザがより高いレベルの保護、制御、保証を備えたハイブリッド環境を使用できるようにします。

Entrustは他のBYOKソリューションを提供していいますか？
Entrust KeyControl（旧HyTrust）は、暗号化ワークロードのためのユニバーサルな鍵管理システムで、クラウドユーザがパブリッククラウド全体で暗号鍵の管理を自動化および拡張できるようにするものです。KeyControlはAmazon Web Services（AWS）とMicrosoft Azureのネイティブキーをサポートしており、マスターキーの完全な制御を可能にします。複数のパブリッククラウドサービスに対応する予定であり、クラウドユーザのクラウド導入戦略の拡大に合わせて、鍵の安全性を常に確保することができます。
詳細な操作方法については、こちらのブログで紹介しています。

なぜBYOKが必要なのか？
暗号化されたデータのセキュリティは、暗号鍵に与えられる保護と同じだけ優れています。BYOKは、単一のクラウドサービスプロバイダー、ハイブリッド、またはマルチクラウド戦略のいずれを展開する場合でも、クラウドユーザが必要とする制御と保証を提供します。BYOKとHSMの使用により、クラウド・ユーザは、1つのCSPから別のCSPへの移行を困難にするベンダー・ロックインに関連する問題を回避することができます。HSMは、ハッカーが重要な暗号鍵を見つけるのを阻止するために、ソフトウェアではなく、耐改ざん性のある場所に配置するよう特別に設計されています。企業が安心してクラウドに完全移行するために、BYOKはnShield as a Serviceを使用して、設備投資なしで、オンプレミスのソリューションと同じレベルのセキュリティと保証で展開することが可能です。

タグ: ,

クラウド管理者のための5つの集中型ロギング のベストプラクティス

投稿日: 2022年1月3日 クライム
クラウド・仮想インフラ

多くの企業では、ロギングが複数のクラウドプロバイダ、データセンター、デバイス、アプリケーションに分散されており、この状況はクラウドの管理タスクを複雑化させる可能性があります。

また、ログソースの形式やアクセス方法もさまざまです。このような多様なログ取得の常習は、問題の診断、キャパシティ・プランニング、セキュリティおよびコンプライアンス・ポリシーの監視にログを効果的に活用することを阻みます。ハイブリッドおよびマルチクラウド環境では、アプリケーションのコンポーネントと依存関係の可視化を維持するために、ログの一元化が不可欠です。

まずは、以下の集中型ログのベストプラクティスを考察してみます。

1. ロギングの目標を理解する

最初にクラウドのロギングとアプリケーション・パフォーマンス管理（APM）の要件の範囲を検討します。管理者がクラウドAPMとロギングの一元化をどのように実現するかは、使用するクラウド・コンピューティング・モデルに依存します。

●単一のパブリック・クラウド：クラウド・プロバイダーが提供するクラウド・ネイティブ・ロギング・ツールを選択します。

●ハイブリッド・クラウド：現在のオンプレミスのロギング手法をクラウドに拡張します。

●マルチ-クラウド：何らかの形でログを集計し、収集したデータを分析する。

さらに、ログ収集したデータの用途と、ログ収集したイベントをリアルタイムで確認する必要があるかどうかを検討します。リアルタイムのデータ収集は、集中型ログのコストと複雑さを高めることになります。しかし、管理者が問題が発生したときに中央のログを使用して診断することを期待する場合は、それが不可欠です。

2. アプリケーションロギングとリソースロギングの分離

アプリケーションのロギングとリソースのロギングは、それぞれ別のレイヤーであるべきです。アプリケーションは、多くの場合、それ自身の状態を記録します。プラットフォーム・リソースのログ（ホスティングやミドルウェアのログ）は、常に利用可能です。一元化の目的はすべてを取りまとめることですが、この2つのログ・ソースを混在させないようにすべきです。効果的なAPMの実践は、問題をアプリケーションとリソースをそれぞれに分離することにかかっています。

管理者は、アプリケーションとその基盤となるリソースとの関係を判断するために、情報を記録する必要があります。クラウドやその他の仮想ホスティング技術では、アプリケーションが仮想リソースを可視化するため、アプリケーションとホスティング・リソースの間の接続はソフトなものになります。このため、アプリケーションと物理リソースの対応付けを行い、2つのログレイヤの意味を理解することが重要です。物理リソースを共有するアプリケーションは仮想リソースを共有しないため、このマッピングは問題の関連付けにも重要です。

3. 何をどれだけの期間記録するかを知る

どんなに優れた集中型ログ記録戦略であっても、データ量に埋没してしまうことがあります。管理者があまりにも多くのログデータを保存すると、パフォーマンスに悪影響を及ぼし、コストが上昇し、有用な情報を見分けるのが困難となります。ログを取るためだけにログを取るのではなく、何かをログに取るという具体的な理由が必要です。

管理者は、一元的にログを記録するように選択したものについて慎重であるとしても、少なくとも年に2回はログ記録プロセスを見直し、収集したデータのうち使用されなかったものを確認する必要があります。また、個人を特定できるような情報は記録しないようにしましょう。これは、セキュリティやコンプライアンスに関するポリシーに違反する可能性が高いからです。

4. ログデータの可視化

テキストによる分析に加え、ログデータの有益なビジュアル化を達成する。多くの企業が、中央のログをあまり活用していないことを認めています。管理者が余計なデータの記録を避けていても、迷路のようなテキスト情報の中から何かを見つけ出すのは困難な場合があるからです。ログ管理ツールを評価する際には、ログの可視化機能を優先する必要があります。

5. 適切なログ管理ツールの選択

集中管理型ログ取得ツールには様々な選択肢があります。適切なものを選択するために、組織はクラウド・プロバイダーが提供するものとサードパーティーやオープンソースのツールとを比較する必要があります。

●プロバイダー・ネイティブ・ツール：AWS、Microsoft Azure、Google Cloudは、Amazon CloudWatch Logs、Azure Monitor Logs、Google Cloud Loggingなど、さまざまなログ管理ツールを提供している。これらのプロバイダーは、クラウドログデータ収集と、ハイブリッドおよびマルチクラウドログを取り込むことができるツールの両方を提供しています。一般的に、企業は支配的なプロバイダーのクラウドログのフレームワークを採用し、他のログを取り込むことが最も簡単です。

●サードパーティの選択肢 ：サードパーティ製品（一部はオープンソース技術をベースにしている）には、Dynatrace、Datadog、New Relic、Splunkなどがあります。これらの製品の多くは、可視化と集中収集の機能を備えたAPMスイートです。

 ●オープンソースの選択肢： オープンソースの選択肢としては、Elastic Stack、Graylog、Fluentd、Rsyslog、LOGalyze、SolarWinds、NXLogなどがあります。これらの製品は、セルフサポート版とエンタープライズ版の両方が用意されているが、機能は大きく異なるので、各製品を注意深く確認ください。ただし、パブリック・クラウド・プロバイダーを持たない企業や、主にオンプレミスのロギングに注力している企業、カスタムな取得を必要とするログがある場合は、これらのオープンソース・オプションのいずれかが最適となる可能性があります。

集中型ロギングおよびモニタリング製品を慎重に選択することです。APMの実践を妨げず、可視性や情報の明瞭性を変化させるリスクなしに製品を変更することは困難です。いつも適切な計画を立てることが重要です。

タグ:

ハイブリッドクラウドには互換性のあるデータ戦略が必要

投稿日: 2021年12月30日 クライム
クラウド・仮想インフラ

ハイブリッドクラウドは優れたIT戦略ですが、互換性のあるデータ管理プランがなければ、企業のリソースは効率的に活用できません。

プライベートクラウドだけでなく、複数のパブリッククラウド・プロバイダーにワークロードを展開する企業が増えていて、ハイブリッドクラウドの世界になってきています。もちろん、クラウドに移行する正当な理由はたくさんあります。計算能力の柔軟性や、最新のアプリケーション環境の必要性などです。

しかし、ほとんどの企業で十分に考えられていないのが、互換性のあるデータ管理機能という観点からハイブリッドコンピューティングを考える必要がある分野です。

つまり、ハイブリッドコンピューティングモデルを最大限に活用するためには、パブリッククラウドやプライベートクラウド、オンプレミスのデータセンター、さらには複数組織でのデータ交換など、ユーザが納得できる場所でデータを操作し、それを最小限のあつれきで実現できるデータモデルを採用することも必要なのです。

データからスタート

ハイブリッドクラウド戦略の第一歩は、データそのものをポータブルにし、完全に管理できるようにすることです。実際には究極の目標は、分析およびAIソフトウェアプラットフォームに、すべてのパブリックおよびプライベートクラウドの実装で利用可能な統一されたデータリポジトリを提供しつつ、あらゆるクラウドプラットフォーム上のあらゆるワークロードを透過的にサポートできる真のクロスプラットフォームに向けて進化させることです。

このようなソリューションでは、さまざまなワークロードがデータを利用できるようにするために、多くの機能を実装する必要があります。また、オンプレミスのデータレプリケーションやグローバルなデータ検索、規制要件を満たすためのデータガバナンスなど、すべてのデータを管理する共通の管理プレーンを含む、安全でスケーラブルでかつ弾力的な環境に存在しなければなりません。

このソリューションは、幅広いテンプレート範囲とプラットフォーム間でのランタイムの互換性を持ち、主要なパブリッククラウド（AWS、Azure、GCP）で動作し、さらにAIアクセラレータ（Nvidiaなど）で動作することが必要です。データウェアハウスおよび/または個々のクラウドプロバイダーによる独自のデータストレージ・ソリューションを使用すると、データ資産価値の最大化を妨げ、容易な移動の妨げになってしまいます。

データ品質より重要なものは無し

分散型ハイブリッド環境におけるもう一つの重要な考慮すべき点は、多くの企業がAI対応システムに移行し、データセットに基づくモデルを構築するにつれ、データの品質を確認することがより重要になることです。破損したデータに基づいての機械学習や人工知能アルゴリズムに使用されるモデルは、悪いモデル、そして信頼性の低い洞察力を生み出してしまいます。

企業データの価値を最大化し、そのデータから提供される質の高いインサイトを直接的に推進するために、企業はクリーンで最新の、完全に管理された安全なデータを提供するデータプラットフォームを必要としています。また、個人だけでなく、AIモデルやワークロードプロセスなど、誰がデータに「触れたか」を確認できる機能も必要です。

これを実現するには、データの系統を追跡することが重要ですが、すべてのデータウェアハウスがそのような機能を容易に提供できるわけではありません。

データ処理をオンプレミスからクラウドへ

企業組織は、コンテナやマイクロサービスなどのクラウドベースのモダンなアプリケーション戦略を採用し、まずオンプレミスで使用し、その後パブリッククラウドに移行することからクラウドへの移行を始めることが多いようです。この手法は安全な実験を可能にし、どのワークロードが安全かつ効果的にパブリッククラウドに移行でき、どれがオンプレミスに留まるのが最適かを確認することができます。

クラウド上のワークロードをオンプレミスに戻したり、必要に応じて別のパブリッククラウドプロバイダーに移行したりすることもできるため、この方法は一方通行にはなりません。そのためには、アプリケーションとデータの両方をクラウド間で移動できないような、独自のAPIやシステム・コンポーネントを使用してロックダウンしないクラウドインスタンスを作成する方法が必要です。ロックインは、完全にオープンなクラウド環境を言い張るベンダーであっても、現実的な問題です。要は、ロックインされた環境では、データを適切に管理することができないということです。

最適なデータ・プラットフォームを選択する

エンタープライズ型のハイブリッド対応データプラットフォームを使用することで、オンプレミスまたはクラウド上のさまざまなプロセッサで動作する必要なワークロードにデータを移動する能力が向上します。さらに、シングル・インスタンスを管理し、多様なデータセットを複数のプラットフォームに分散させないことで、データの品質を確かなものにします。

さらに、規制の厳しい業界や地理的な制約のある環境では、データのガバナンスを最大限に高めることが、規制による罰金やデータ漏洩の防止に不可欠です。最終的に、トップクラスのデータプラットフォームは、一度書き込めばどのクラウド環境でも実行できるようになり、ワークロードの処理能力を真の意味で種々さまざまな組み合わせるできるようになると想定します。ハイブリッドクラウド環境から最大限の利益を得ようとするならば、企業は真のハイブリッド対応データクラウド機能を設定する必要があります。

ご意見・ご要望があればご連絡ください

タグ: , , ,

サイバーセキュリティに関する8つのバッドプラクティス

投稿日: 2021年11月21日 クライム
セキュリティ

バッドプラクティス　#1：「自分には起こらない」

人生に悪いことが起こるかもしれないと考えるのは、誰でも好きではありません。しかし、そのような習慣が、サイバーセキュリティ上の最悪の慣行の1つとなってしまうのはなぜでしょうか。

ユーザのネットワークは常に攻撃を受けています。悪意ある者は抜け道を探し、ボットは開いたポートを探し、大量のフィッシングメールが毎日あなたやあなたのエンドユーザに送られてきます。そして、これらの攻撃のうち、少なくとも1つが成功する可能性は驚くほど高いのです。この時点で、このような攻撃はもっぱらエンタープライズクラスの企業を対象としたものであり、”自分ような小さな会社には起こらない “と言う人もいるかもしれません。しかし、そのような意見は大きな間違いです。

たしかに、サイバー犯罪者は、エンタープライズ級の身代金を求めて、エンタープライズ級の企業を狙っています。しかし、彼らは通常、エンタープライズグレードのサイバーセキュリティポリシーと技術に直面します。一方中小企業について言えば、確かに支払われる身代金の平均額は少ないでしょうが、中小企業が徹底したサイバープロテクションを実施している可能性も著しく低いと言えます。

調査会社によると、中小企業の44%が過去に一度はランサムウェアの被害に遭い、48%が複数回被害に遭っているとのことです。また、約70％の中小企業がサイバー攻撃に対して十分な保護を実施してはいません。

では、このような「自分たちには起こらないだろう」という考えは一体なぜ出てくるのでしょうか。それは、徹底したサイバーセキュリティ・ソリューションを導入するために必要な費用や複雑さが原因です。確かに費用はかかりますし、本格的なSIEMスイートや追加のセキュリティエンジニアのために予算が必要でしょう。そして、複雑さという要素も出てきます。監査、修正、維持、管理、設定、そしてこれを定期的に行う必要があります。
結局、ほとんどの人は「うちには高額で複雑すぎる」で、攻撃は大企業が対象と考え始める傾向にあります。

バッドプラクティス #2：最近の攻撃について無頓着である

さて、あなたは侵入されました。復旧に成功し、結果を修正しました。復旧したのだからこれで十分だと考えがちですが、そうではありません。しかし、そうではありません。この時点でやるべきことは、セキュリティ監査を行い、攻撃を可能にしたネットワークの欠陥を見つけて修正することです。

一方で、他の人に起こっている攻撃について知らないでいるわけにはいきません。ニュースをチェックして、自社のインフラを守るために学べる新しい攻撃パターンがないかどうかを判断しましょう。

バッドプラクティス #3：基本に忠実であること

攻撃は年々進化し、悪意ある者は新たな方法であなたの防御を潜り抜けてきます。そして、サイバーセキュリティ市場はこれに答えを出しています。新しいツールやアプローチが登場し、言うまでもなく、インフラ全体を防御することができる新しい複合プラットフォームも登場します。

本当にすべきでないのは、昔から使っている「古き良き」アプリケーションのままでいることです。

バッドプラクティス #4：不適切なパスワード・セキュリティルール

パスワードポリシーは、ネットワーク、メールサービス、クラウドアプリケーションを狙った攻撃の最初の砦です。このサービスには誰も侵入してこないだろうから、パスワードは『123456admin』にしておこう」などと考えていると、すぐに大惨事に見舞われることになります。

また、パスワード・セキュリティのワースト・プラクティスとして、さらに2つの注意点があります。

●ユーザにパスワードを選ばせる。信じられないかもしれませんが、本当に安全なパスワードを選ぶユーザはいません。大体はユーザの犬の名前になるでしょう。

●ユーザに管理者権限を与える。技術者の中には、トラブルシューティングの際にユーザーに管理者権限を与えてしまい、それを忘れてしまう人がいます。これはセキュリティ上の抜け道ではなく、セキュリティ上の悪夢です。ユーザのマシンを通してネットワーク全体に侵入する絶好の機会なのです。

バッドプラクティス #5：適切な文書化がなされていない

パスワードが安全で強力なものになり、ネットワークがしっかりと保護され、アプリケーションが最新のものになったら、セキュリティポリシーをレベルアップする時です。そのためには、インシデント対応計画や最近発生したインシデントの事後調査など、適切な文書を作成する必要があります。

その理由は簡単です。ランサムウェアの侵入が成功した場合のアクションプランがあるかどうか、自問してみてください。また、エンドユーザは、ランサムウェアの侵入に気づいた場合、どのように行動すべきか、誰に通知すべきかを知っていますか？十分に文書化され、認知されたインシデント対応計画があり、従業員や技術スタッフがそれに基づいてトレーニングを受けていれば、初めての攻撃にいち早く気づき、その影響を最小限に抑えることができます。

バッドプラクティス＃6：新技術の無頓着な導入

CEOやCTOの中には、市場に出回っているあらゆる技術トレンドを追いかけがちな人がいます。その結果、ネットワーク、インフラ、アプリケーションのポートフォリオが混沌とし、管理しきれなくなることがあります。何十もの統合、相互に接続された多くのセキュリティルール、安全に管理できる以上のエンドユーザのパスワードなどに直面することになります。

このような状況では、攻撃手段の数が増えてしまいます。しかし、誤解しないでいただきたいのは、新しい技術を恐れるべきではないということです。ほとんどの場合、会社の運用能力を向上させるためには必要不可欠なものです。しかし、適切な計画を立てずに導入すると、事態はコントロール不能に陥ります。

バッドプラクティス　＃7：監査や評価を行わない

現在では、小規模な組織を運営している場合でも、相互に接続された少なくとも十数個のクラウドやローカルのアプリケーション、ネットワークサービスを管理しています。言うまでもなく、パンデミック後は自宅で仕事をする文化が根付いており、リソースが分散化されています。

そのため、ネットワークに何が起こっているのかを気にしすぎてしまうか、あるいは悪意のある人物が幸運にもインフラの穴を見つけて利用するまで、「設定したらそのまま忘れてしまう」ということになってしまうのです。

バッドプラクティス　＃8：セキュリティ意識向上のためのトレーニングが行われていない

ネットワークがダウンすると、「いつもDNSが原因だ」と言う人がいます。また、攻撃を受けたときに「いつもエンドユーザが原因だ」と言う人もいます。この両者は、少なくともある程度は正しいと言えます。

多くの攻撃は、エンドユーザがトレーニングを受けていないことを期待して、エンドユーザを狙っています。そのような攻撃には様々な種類があります。例えば、人を騙して破損したファイルをダウンロードさせようとするフィッシングやスピアフィッシングのメール、脆弱なパスワードに対するブルートフォース攻撃、強力なパスワードを発見するためのソーシャルエンジニアリングなどです。

そして、日常的なサイバーセキュリティのトレーニングではなく、自分の仕事をすることに集中している普通の人は、このようなすべてのことに対して準備ができていないのです。ですから、標準や慣行に従わないユーザを馬鹿にしたり、怒ったりするのは不公平です。彼らはそもそもそのような慣行について知らないのです。

適切な教育と定期的なトレーニングがなければ、ユーザはサイバーセキュリティの最大の穴になってしまいます。経験豊富なシステム管理者は、適切なトレーニングを受けたとしても、ほとんどのユーザが物事を忘れたり、混同したりする傾向があることを知っていますが、少なくとも一部のユーザは、次回開くメールに注意を払うでしょう。

参考 >> クライムが提供するランサムウェア対策手法

タグ: ,

Office 365のバックアップで回避すべき5つのよくある失敗

投稿日: 2021年11月1日 クライム
クラウド・仮想インフラ ディザスタ・リカバリ

電子メールなどのサービスをSaaS型ソリューション（Microsoft Office 365など）に移行した場合、データの保護と可用性について誰が責任を負うのかが必ずしも明確ではありません。プロバイダのバックアップ・ツールに頼るだけでは、データを安全かつ利用可能な状態に保つことはできません。データが破損したときに、すでに手遅れで、ビジネスデータに大きな影響を与える可能性があります。

Office 365への移行計画では、必ずしもすべての関連手順が考慮されているわけではありません。また、ビジネスの最も重要な側面であるデータ保護への配慮が不十分な場合もあります。

1. Office 365環境のバックアップがない

Office 365プラットフォームでビジネスを展開する場合、マイクロソフトの責任とユーザの責任を確実に理解する必要があります。契約上、マイクロソフトはOffice 365インフラの可用性のみを保証し、保存データは保証しません。ユーザは、データの整合性と可用性を確保するために、Office 365環境を保護しなければなりません。

誤って削除、変更、または上書きされたアイテムは、適切なバックアップ戦略がなければ回復できません。マイクロソフトは最低限の保護を提供していますが、マイクロソフトが設定した保存ポリシー（通常30日）は、企業の要求と矛盾したり、異なったりする場合があります。

2. 3-2-1バックアップルールに準拠していないバックアップ

優れた効率的なバックアップ設計は、3-2-1バックアップルールに準拠していなければなりません。

●3つのバックアップ・コピー : 1つのバックアップだけでは、データの整合性と可用性を保証するのに十分ではなく、特に単一障害点に保存されている場合です。
●2つの異なるストレージメディア ： 1つのストレージにバックアップを保存し、そのコピーをテープやクラウドに保存することで、1つのメディアが故障した場合でもデータを保護することができます。
●1つのオフサイト・バックアップ ： オフサイト・ストレージにコピーを保管することで、プライマリ・サイトが災害に見舞われた場合でもデータの可用性を確保することができます。

本番環境と同じ場所に1つのバックアップを持つことは、プライマリサイト（この例ではマイクロソフトのクラウド）に何か重大な問題が発生した場合には良いアイデアではありません。バックアップからデータにアクセスしたり復元したりする必要があり、すべてがクラウドにのみ保存されている場合、クラウド・プロバイダーに何らかの問題が発生したらどうなるでしょうか？データにアクセスできなくなり、企業にとってはコストがかかることになります。

バックアップインフラを設計する際には、このシンプルなルールに従うようにしてください。

3. すべてのアイテムやサービスを保護できない

Office 365はメールだけを提供しているわけではありません。連絡先、カレンダー、タスク、OneDrive、SharePointなどは、企業がビジネスで使用する可能性のある追加サービスです。サービスの中断やデータの損失を避けるためには、これらのコンポーネントをすべて保護することが非常に重要です。

Exchange Online
OneDrive for Business
SharePoint Online
連絡先およびカレンダなどのコンポーネント

4. 侵入者からバックアップを守る
バックアップで最も重要な点は、本番データが含まれていることです。もしデータが悪用された場合には、機密データが漏洩する可能性があり、組織にとって大きな問題となります。

バックアップを保護するためには、データを盗み見されないようにする必要がありますが、そのためには、データのバックアップを暗号化し、盗み見されても読めないようにする必要があります。

5. ランサムウェアへの対策がない

ランサムウェアは、近年、企業がビジネスデータに対して経験した最も一般的な攻撃であると思われます。適切なバックアップ戦略がなければ、データは重大な危険にさらされ、多くの場合、永久に失われます。バックアップを実行する際には、データの完全性と可用性を確保する必要があります。バックアップは、削除、変更、および意図的な上書きから保護されなければなりません。

最新技術では、管理者はデータを「不変 (Immutable）」に保護することができるバックアップソリューションを利用することができます。例えば、Amazon S3やWasabiのような、XFSベースのバックアップリポジトリや、オブジェクトロック機能を備えたオブジェクトストレージソリューションを利用します。

タグ: , ,

VDIの災害対策のためのオプション検討

投稿日: 2021年9月28日 クライム
その他製品・ツール クラウド・仮想インフラ

すべてのVDI導入には災害対策(災害対策：DR)を含めるべきで、IT管理者は、災害対策計画を複雑にする可能性のあるVDI特有の依存関係とリスクを認識する必要があります。

VDIセッションがデータセンターから離れると、問題が発生しやすくなります。特にデータが海外の場合はそうです。VDIインフラが完全に故障した場合、社内のシンクライアント・ユーザもデータを失うことになります。

膨大なコストをかけずにVDIの災害対策を実現するには、いくつかの選択肢があります。

分割
IT管理者は、VDIデスクトップとサポートインフラを2つの物理的なデータセンターに分割することで、リスクを減らすことができます。1つのデータセンタが利用できなくなっても、少なくとも半分のVDIセッションにはアクセスできます。この場合、IT部門は、2つのデータセンタが共通の依存関係を持たないようにする必要があります。

VDIは冗長化する必要がありますが、VDIインスタンスは日常のアプリケーションに接続できる必要があります。また、VDIインスタンスは、Active Directory（AD）などの認証・管理ツールに接続する必要があります。IT部門は、依存関係を理解し、頻繁にテストを行って、これを確認する必要があります。

クラウドへの移行
データセンターが1つしかなく、環境も予算も限られている場合、VDIインスタンスを分割することは、VDIの災害対策のための実行可能なプランではありません。このような状況の組織は、デスクトップ・アズ・ア・サービスを利用してVDIを保護することができます。例えば、VMware社は、いくつかの有名なクラウドプラットフォーム上でマネージドVDIサービスを提供しています。また、自社のAzure ADインフラを利用して、基盤となるADサービスを提供することもできます。

VDIは冗長化する必要がありますが、VDIインスタンスは日常的なアプリケーションに接続できなければなりません。しかし、これらのクラウド・サービスは、現状ではオンサイトとクラウドの両方のインフラを管理することはできません。これを回避するには、IT部門が2つの別々のインフラをセットアップする必要があります。2つのサイトを管理するのは問題があると思われるかもしれません。しかし、最悪の事態が発生しても、IT部門は新しいVDIデスクトップを迅速かつ容易に立ち上げることができます。それがクラウド環境の良いところです。

また、セカンダリのネットワーク拠点がある場合は、セカンダリのVDIインフラを立ち上げることもできます。ハイパーコンバージドインフラでは、高価なストレージエリアネットワークインフラに投資することなく、数ユニット分のラックスペースで仮想インフラ全体を立ち上げることができます。

しかし、DRの設定は後から行うことはできません。このような設定を利用するには、IT管理者が積極的にVMwareと連携する必要があります。また、イメージの管理やグループの設定など、いくつかの作業を行う必要があります。

インスタント・フェイルオーバー製品の活用
IT担当者は、ZertoやVeeamなどの従来のインスタント・フェイルオーバーDRツールをVDIに使用することができますが、いくつかの注意点があります。

例えば、VMware Horizonでは、リンクモードやインスタントクローンを使用しており、ディスク構成やリンクの点で新しいVDIインスタンスを実装する際に非標準的な方法を使用しています。ほとんどのDRツールはこれにうまく対応できいない可能性があります。

インスタント・フェイルオーバーDRツールの中には、AccopsなどのVDIに対応しているものもありますが、IT管理者はこれらのツールの使用やテストに細心の注意を払う必要があります。また、時間の経過とともに変化する可能性があるため、ベンダーに確認する必要があります。

タグ: ,

VMware vSphereでのフルVMリストアのパフォーマンスについて

投稿日: クライム
VMware vSphere トラブル

ユーザが、新しく購入した超大型SANで高速のリストアパフォーマンスを期待していたが、良い数値が得られないという話を聞きます。特に、オールフラッシュアレイ(AFA)を購入し、すべてが順調に進むことを期待していたユーザにとっては、ショックでイライラすることでしょう。では、一体何がこの問題を引き起こしているのでしょうか？最近ではほとんどのVM（仮想マシン）がシンプロビジョニングされているため、リストア時にディスクに書き込む際、ESXiはデータを書き込む前にゼロを書き込む必要があります。最近のSANには、ディスク領域をゼロにするためのハードウェアアクセラレーション（通称VAAI）が搭載されており、VMの作成やVMDKのフォーマット時にかかる時間やネットワーク負荷を大幅に軽減することができます。また、帯域幅やIOPSが制限されている場合のパフォーマンス回復にも役立ちます。この機能がないと、ESXiは従来の方法でゼロを書き込む必要があり、書き込み量が事実上2倍になってしまいます。しかし、この機能はハードウェアのWRITE_SAMEコマンドに依存しています。WRITE_SAMEコマンドはシリアル化されたコマンドであるため、ほとんどのドライブやコントローラーはこの呼び出し中に他のすべてのIOをブロックし、同様に一部のシステムは特定の速度でロックされてしまいます。

実際にこれはTRIMコマンドの動作と非常によく似ています。大量のTRIMコマンドを発行すると、ドライブ全体の実行が停止し、他のI/Oはただ待っているだけのような状態になります。同様にコントローラはWRITE_SAMEコマンドを完了しないと、I/O処理に戻ることができません。イメージベースのリストアは「ブロック単位」で行われるため、このゼロイングアウト(zeroing out)によって各リクエストにかなりのレイテンシーが加わることになります。おそらく数ミリ秒程度だとは思いますが、1MBのブロックでは1msの遅延でも1秒間に1000回の書き込み、つまり理論上の最大値は1000MB/sになります。2～3msの場合は、それぞれ500MB/s、333MB/sにまで落ち込みます。しかし、AFAのようなマイクロ秒単位の書き込み応答時間を持つ超高速ストレージに書き込む場合、各リクエストにミリ秒単位のレイテンシーを加えると、これらのシステムが提供できる実パフォーマンスに大きな影響を与えます。しかし、この機能はランタイム中に無効にすることができるので、リストア前にオフにし、その後オンにすることをお勧めします。

この方法についてのVMware KBの記事は以下の通りです。> Disabling Hardware Accelerated Init (WRITESAME) in ESXi


（注）TRIMはオペレーティング・システムからソリッドステートドライブ（SSD）の未使用領域を内部的に消去するために用いられるコマンド

＊バックアップ仙人のアドバイスから

タグ:

NASデバイスのバックアップを保護するためのヒント

投稿日: 2021年9月26日 クライム
クラウド・仮想インフラ ディザスタ・リカバリ

NASデバイスは、あらゆる規模の企業に信頼できるデータストレージとして提供されています。そのデータをバックアップするには、企業は追加のデータ保護対策を実施する必要があります。

ネットワーク接続型のストレージシステム（NAS)では、データを外付けの物理ドライブに保存するため、バックアップやリカバリーの機能が組み込まれていないことが多いが、幸いなことに複数のNASデバイスのバックアップ方法が簡単かつ広く利用可能です。


NASのOSはパフォーマンスに最適化されており、一般的なバックアップソフトウェアのエージェントは含まれていません。以前は、NASデバイスから大量のデータをバックアップする唯一の方法は、テープを別の場所に輸送するという長いプロセスを必要としました。圧縮技術とクラウドの台頭により、NASデバイスのバックアップは非常に簡単になりました。

NASの使用例

あらゆる種類や規模の企業が、あらゆる形態や量のデジタルコンテンツを安全にバックアップし、リカバリーするためにNASを使用しています。このステップは、ハードウェアの故障、災害、内部または外部のネットワーク攻撃の際には情報を保護します。

最も一般的な使用例は、非構造化データの保存です。構造化データは、データベースやエンタープライズコンテンツ管理システムなどの組織化されたシステムに存在しますが、非構造化データは別の問題です。

非構造化(unstructured)データとは、どこかに保存しなければならないその他のデータのことで、できれば、意味のあるファイルやディレクトリ階層を作成して整理したいものです。
さらに、特にSMB分野では、NASデバイスは、個々のユーザーや部門全体がアクセスする文書やマルチメディアファイルを保存する中心的な役割を果たすことが多いです。大企業では、サーバがNASデバイスからデータをマウントすることが多く、OSファイルから重要な分離が保たれています。

一般的なNASバックアップの課題

企業が取り組むべきNASデバイスのバックアップに関する最も重要な課題は、バックアップ・リカバリーツールの導入を忘れないことです。

運用意識の低い組織では、NASを購入しても、いったん保存されたデータを保護するシステムの設計を怠ってしまうことがよくあります。

NASデバイスは、ミラーリングやパリティ機能を備えたマルチディスクシステムです。これらのメカニズムは、ディスクが故障した場合にのみデータを保護します。誤って削除されたファイルやランサムウェアからの攻撃を防ぐことはできません。

従来のNASのバックアップでは、NASをバックアップメディアサーバーなどの別の外部機器にバックアップする必要がありました。その後、メディアサーバーをオフサイトのテープストレージにバックアップします。この方法では、時間とコストがかかるという問題があります。

最新のNASデバイスのバックアップ手法を比較
最適なNASのバックアップ方法は、組織によって異なります。既存のインフラや、データの量と種類によって、どのNASバックアップ方法が最適かが変わります。NASのバックアップを作成する基本的な方法は、圧縮や重複排除によるデータ削減、スナップショット、クラウドベースのストレージの3つです。

1.  圧縮および/または重複排除: 圧縮と重複排除は、バックアップ・ターゲットが必要とするストレージの容量を削減するデータ削減方法です。必要な容量が減れば、バックアップ・サーバはプライマリソースと1対1の比率でストレージ容量を含む必要はありません。圧縮または重複排除の比率は、データの種類に応じて異なります。

2. スナップショット・バックアップ：ストレージ・スナップショットは、目次のような役割を果たすデータ参照マーカーです。ユーザは特定の時点のデータのコピーに簡単にアクセスすることができます。スナップショットは、特に変更の少ないシステムにおいて、スペース効率の高いアプローチを提供します。

一方で、ストレージスナップショットはバックアップソリューションとしてよく宣伝されていますが、これは誤解を招く恐れがあります。スナップショットは、二次メディアにコピーされない限り、メディアの障害から完全には保護されません。スナップショットはNASデバイスのバックアップツールとして役立ちますが、フルバックアップの代わりにはなりません。

3. パブリック・クラウド:パブリック・クラウドは、安全なオフサイト・バックアップ・ターゲットであり、最も一般的なNASデバイスのバックアップ方法です。

今日のNASデバイスは、AWS、Microsoft Azure、Wasabiなどの一般的なクラウド・ストレージプロバイダーとの統合をサポートする必要があります。クラウドプロバイダーと連携することで、バックアップ管理者は、バックアップの頻度や保存期間を設定することができます。パブリック・クラウドとNASの統合により、組織のバックアップ・ポリシーの一環として、クラウドのターゲットに直接対応することができます。

あらゆる規模のNASベンダーが、クラウドストレージの統合をサポートしています。クラウドバックアップ統合の課題は、通常、NASデバイスではなく、適切なクラウド・プロバイダーを見つけることです。様々なベンダーが提供するいくつかの重要な要素があります。チャレンジは、それらを組み合わせてバックアップに利用することです。

マネージド・サービス・プロバイダは、組織のNASデバイスとクラウド・プロバイダのバックアップ・ストレージとの間のギャップを埋めるために、セットアップとデータ保護を担当することができます。マネージド・サービス・プロバイダーには、クラウド・ストレージの使用料、バックアップを監視する日常業務、障害やその他のデータ・ロスト・イベント後のリストアを処理する業務に対する維持サービス料を支払うことになります。

2021/10/14（木）15:00開催Webセミナー[ファイルサーバを高速バックアップ！Veeam NASバックアップのここがスゴイ！]

 

タグ: ,

マルチクラウド戦略の重要性

投稿日: 2021年8月24日 クライム
VMware vSphere クラウド・仮想インフラ

クラウド戦略なしでは企業のITが立ち行かない時代になって久しいですが、近年はそれがマルチクラウド、あるいはハイブリッドクラウドに進化しています。IT調査会社IDCによると、Infrastructure as a Service（IaaS）、 Platform as a Service（PaaS）、Software as a Service（SaaS）を含め、世界のパブリッククラウド市場は2019年の段階で前年比26％増の2,334億ドルに拡大し、それが2020年にはさらに24.1%増の3,120億ドル規模に達しているそうです。オンプレミス環境に依存していた企業が、部分的にパブリッククラウドへ移行するケースも増え、IT環境のハイブリッドクラウド化が進んでいます。

企業はこのような複雑化したインフラストラクチャに従来のツールでは対応できなくなっています。そのような状況をサポートするためにVMwareのようなベンダーも、vSphereのマルチクラウド サポートを拡充するなど、新しい時代のインフラストラクチャへの対応を充実化させています。具体的には、VMware Cloud FoundationやCloudHealthなどを活用したシステムの可視化、コスト管理、セキュリティとガバナンスの機能を提供し、さまざまなクラウド環境にまたがるインフラストラクチャの一貫した運用・管理を可能にしています。

しかし、企業がこのような新しいツールを有効に活用するには、マルチクラウド戦略の構築あるいは見直しが欠かせません。ツールだけが刷新されても、企業内の体制が整っていないければ、ひずみが生じて、効率性やセキュリティを犠牲にしなければならなくなってしまいます。

特に、コンテナやマイクロサービス、Kubernetesの導入は、インフラストラクチャの根本的な設計をくつがえし、従来型のデータセンター管理に大きな変革をもたらしています。

データ管理プラットフォームの革新

データはかつて一定のパターンに沿ってシステムに取り込まれ、それをそのまま把握し、監視することがデータ管理ツールの役割でした。システム間の接続ポイントでデータを監視し、1つの場所から他の場所に移る際に情報を集めて、比較すればよかったのです。

しかし、マイクロサービスではアプリケーションを細分化するので、データサービスとの連携も多様化され、かつてのような右から左への分かりやすいフローが存在しません。当然ながら、システム管理者は新しいツールに慣れるまでに時間がかかります。特に、従来型のツールに慣れ親しんだシステム管理者が、経験をアップデートするには、単に新しいツールに慣れる以上の労を要するかもしれません。企業のマルチクラウド戦略は、スタッフの教育を考慮に入れ、少しずつ理解を深められるような導入プロセスを策定する必要があります。

企業レベルで全体を俯瞰した視点が重要

マルチクラウド戦略には、部門ごとでなく、企業レベルで全体を俯瞰した視点が重要になります。アプリケーションは個々に複雑さやメンテナンス要件が異なります。クラウドに移行する際も、リスクの高いものと低いもの、移行によって得られる利点が大きなものと小さなものなど、アプリケーションの適性がそれぞれ異なります。企業レベルで個々のアプリケーションを評価し、優先順位をつける必要があります。それによって、移行プロセスを段階的に進め、その都度、プロセスの見直しと改善を繰り返してレベルアップを図ることができます。同時に、スタッフ教育を段階的に深められる点でも理に適っています。

アプリケーションの適性を見極める

マルチクラウドのデプロイメントは、オンプレミスのデータセンターとパブリッククラウドにまたがるケースが多く見られます。VMwareアプリケーションをオンプレミスに保持し、新規に開発・導入するシステムをパブリッククラウドにデプロイする企業も少なくありません。一から導入するシステムであれば、従来のやり方の制約を受けずに、そのまま新しい方式に当てはめることができます。

いずれにせよ、企業はこのような既存のアプリケーションと新しいアプリケーションを含めたエコシステム全体を俯瞰し、それぞれの特徴を理解することが重要になります。前述のように、マルチクラウド戦略には段階的で長期的な視野が必要であり、個々のアプリケーションのクラウド適性を見極め、その相互関係を将来的にも継続的に見直していかなければなりません。各アプリケーションを担当するシステム管理者が他のアプリケーションとの関係も理解できるようにすることが、長期的に重要な意味を持ちます。ハイブリッドクラウドの仮想環境では、1つのアプリケーションが他のアプリケーションのパフォーマンスに影響を及ぼす可能性もあるので、そのような問題を防ぐためにも、企業内における複数アプリケーションの相互理解を深める戦略が有効になります。

長期的な視野、将来の進化を見据えた対応を

現在VMwareインフラストラクチャを活用する企業は、それを築き上げるのに数年、あるいは十数年の歳月を積み重ねてきたケースが一般的です。パブリッククラウドの活用は、VMwareが近年力を注いできた分野であり、効率性やセキュリティの面からも企業が得られる恩恵は計り知れないのですが、その恩恵は一朝一夕で得られるものではありません。短期的には、プロセスの複雑化、コスト、スタッフ教育などでマイナスの影響が出ることは、ある程度想定しなければなりません。そのうえで、長期的な成功を目指す必要があります。

忘れてならないのは、クラウド アプリケーションを取り巻く環境が今も進化し続けている点です。現時点では、マイクロサービスへの移行に大きな利点が見られないアプリケーションも、数年で状況が一変する可能性があります。そのような流動性を見据えて今から長期的な計画を立てていくことが、企業のIT戦略の重要な柱になるに違いありません。

ノイジーネイバー（うるさい隣人）への対処方法

投稿日: 2021年7月28日 クライム
クラウド・仮想インフラ トラブル 設定

「うるさい隣人」は困りものですが、勝手に押しかけて居座る隣人は、もっとやっかいです。いちばんたちが悪いのは、留守中にあがり込んで冷蔵庫の中をあさったうえにボトルの水を直接飲んで、そのまま戻す隣人です！いや失礼、学生時代のアパートを思い出して、つい話が具体的になってしまいました。

そんなことを思い出した理由は、クラウド環境のNoisy Neighbor（うるさい隣人）問題について考えたからです。ノイジーネイバーとは、リソースを占有して他のワークロードのパフォーマンスを阻害するワークロードのことです。現象としては、「うるさい隣人」というよりも、むしろ「ひとんちに勝手に上がり込んで飲み食いして仕事の邪魔をする隣人」ですよね。まさに人のリソースを使って、パフォーマンスを阻害しているのだから。でも、長屋じゃないんだから、そんな隣人は滅多にいなくて、英語ではNoisy Neighborのほうが、誰もが共感する「迷惑な隣人」の典型なのでしょう。

話を本題に戻すと、IT環境のNoisy Neighborはマルチテナントの仮想環境で生じる問題です。物理環境でも、同じ問題を引き起こすワークロードは存在しますが、専用リソースを無駄遣いするだけで、他のワークロードのリソースを横取りしないので、まぁ自業自得と言ってしまえばそれまでです。

一方、仮想環境ではリソースを共有するので、競合が生じやすく、Noisy Neighbor問題は絶対に見過ごせません。では、Noisy Neighbor問題はどのように対処すべきでしょうか。取るべき手段はいろいろ考えられます。

現実の世界では、もし隣人がうるさかったら、できることは大まかに言えば次の3通りです。

  1. 直接、苦情を言う。
  2. 大家もしくは管理組合を通す。
  3. 引っ越す。

3番目の「引っ越す」は最後の手段であり、クラウド環境では「プロバイダを変える」に相当しますが、現実の世界でも、引っ越せば引っ越した先にも似たり寄ったりの問題があるので、あまりおすすめできません。なので、3は除外し、1と2に絞って、具体的に見ていきましょう。

1.  直接、苦情を言う ＝ 隣人の生活態度を正す

直接、話して、隣人の生活態度を修正できるのなら、それに越したことはありません。仮想環境のワークロードなら、真っ先にすべきはコードを見直すことです。リソースの無題遣いはメモリリークの可能性があるし、I/Oが最適化されていない可能性も大です。これらを防止するには、開発プロセスにストレステストを組み込んで、特に負荷がかかる状態でのワークロードの動作とリソースの使用状況を確認しておくことが大事です。

次に、すべきはリソースを制限することです。すなわち、ワークロードが実行される際にプラットフォームがどう反応すべきかを定義します。VM（仮想マシン）にvCPU（仮想CPU）を適切に割り当てるなど、ワークロードが使用できるプロセッサやストレージのリソースをあらかじめ定義しておくことが重要です。

ワークロードに優先順位を設定することも忘れないでください。業務に直結する重要なワークロードのパフォーマンスが、あまり重要でないワークロードに阻害されるようなことは、絶対に避けなければなりません。

手動介入を可能にすることも重要です。モニタリングシステムを導入して、問題をリアルタイムで検知できるようにすることはもちろん、システム管理者が臨時でワークロードを停止させられるようなイベント設定も欠かせません。なお、仮想環境のモニタリングは不可欠ですが、アパートで隣人の部屋に密かに監視カメラを設置するのはやめましょう。逆に訴えられます。

以上の対策は、コロケーションのマルチテナント環境などで、ワークロード全体にある程度管理の目が行き届く場合に限られます。パブリッククラウド環境では、「うるさい隣人」は赤の他人で直接干渉できないケースがほとんどなので、対応策も違ってきます。

2. 大家もしくは管理組合を通す ＝ クラウド契約を正しく理解して運用する

隣人に直接干渉できない場合は大家さんに相談するのがベストです。マンションなど、大規模な共同住宅では、きちんとした規定があって、問題の処理はすでに形式化されているはずです。同様に、大規模パブリッククラウドでは、ワークロードのコンピューティングおよびストレージ要件を自動管理できるようになっていて、Noisy Neighbor問題は起きにくいことが期待できます。

とは言え、すべて契約次第です。どのような契約で使用しているかによって、パブリッククラウドでのパフォーマンスが制限される場合もあります。

まず、パブリッククラウドの契約を理解することが大前提です。一般的にリソースは使い放題というわけではないし、うるさいのは隣人ではなく、じぶんちだった！なんてこともあり得ます。その場合に、プロバイダは自分のワークロードをどう処理する規定になっているのかを把握しておく必要があります。リソース超過時の費用への影響もあらかじめ理解しておかなければなりません。

クラウドプラットフォーム全体のパフォーマンスもある程度は把握できるようにしておきたいところです。隣人のワークロードは直接可視化できないまでも、全体的なパフォーマンスのデータを揃えて、プロバイダに問い合わせる材料にできます。ここでも重要になるのはモニタリングシステムです。

最後に、スケーラビリティを確保することも忘れないでください。クラウドだから当然スケーラブルだと思っていたら、リソースの割り当てが初期設定で固定されていてびっくり！なんて場合もあります。リソースのプロビジョニングが柔軟で動的に対応してくれるサービスを選択しましょう。

クラウド環境の「うるさい隣人」は、現実社会の「うるさい隣人」よりも、ずっと迷惑な、ビジネスに支障をきたすクリティカルな問題なので、絶対に放っておくことはできません。しかし、モニタリングなど、適切なツールを導入して、きちんとデータを集めさえすれば、クラウド環境の「うるさい隣人」は現実社会の隣人よりもはるかに御しやすく、管理が簡単です。面倒がらずに丁寧に対応しましょう。

XFSファイルシステムとEBSスナップショットによる一貫性のあるバックアップ (AWS)

投稿日: 2021年7月27日 クライム
AWS

XFSは、システムクラッシュ時に数秒の高速な復旧を実現します。XFSファイルシステムとAWS EBSスナップショットを使った一貫性のあるバックアップの作成方法を考察してみます。

XFS FreezeとEBSスナップショットの使用

xfs_freezeは、XFSファイルシステムへのアクセスを一時停止または再開し、一貫性を維持するために使用されます。ファイルシステムがサスペンドされると、すべてのデータがディスクにフラッシュされ、その上ではIOが許可されないため、このファイルシステムを使用するアプリケーションが一時停止したり、ハングアップしたり、最終的には失敗する可能性があります。EBSスナップショットを使用してバックアップを実行する場合、スナップショットを取得する直前にファイルシステムをフリーズし、スナップショットの開始直後にフリーズを解除することができます。EBSスナップショットはポイントインタイムで一貫しているため、EBSスナップショットの作成中にファイルシステムのIOが継続していても、スナップショットの内容には影響しません。「xfs_freeze -f -f」フラグは、指定したXFSファイルシステムをフリーズし、新たな変更ができないようにするために使用します。フリーズコマンドが適用されると、ファイルシステムで進行中のトランザクションはすべて完了することができます。新しい書き込みシステムコールは停止され、ファイルシステムを変更できるその他のコールも停止されます。すべてのデータ、メタデータ、およびログ情報がディスクに書き込まれます。 フリーズしたファイルシステムに書き込もうとするプロセスは，ファイルシステムのフリーズが解除されるまで待機します。 xfs_freeze -u ファイルシステムのフリーズを解除し，IOの再開を許可するには，-uフラグを使用します。フリーズによってブロックされていたファイルシステムの変更は、ブロックが解除され、完了することができます。

N2WS Backup & Recoveryでのxfs_freezeの使用について

N2WS Backup & Recovery は、EC2クラウド向けのエンタープライズクラスのバックアップ＆リカバリーソリューションです。N2WS Backup & Recoveryは、AWS EBSスナップショットを使用してバックアップを実行し、アプリケーションやファイルシステムの静止を実行するバックアップスクリプトをサポートしています。バックアップポリシーに対してバックアップスクリプトを有効にすると、スナップショットを取得する直前に起動される「before」スクリプト、EBSスナップショットの開始直後に起動される「after」スクリプト、スナップショットの完了後に起動される「complete」スクリプトの3つのスクリプトが提供されます。3つのスクリプトをすべて使用することも、一部を使用することもできます。スクリプトが必要ない場合は、何もしない空のスクリプトを用意することができます。

ファイルシステムの一貫性の確認

最後に、バックアップ後、XFSファイルシステムのバックアップが一貫していることを確認したい場合があります。そのためには、ボリュームまたはインスタンス全体をリカバリし、デバイスがアンマウントされた状態でxfs_checkコマンドを実行します。

XFS (eXtents File System )はUnix/Linux系64ビットのジャーナリング・ファイルシステムであり、ファイルシステムの整合性が保証されている。ファイルシステムサイズは最大で8EiBであるが、通常ホストオペレーティング・システムの仕様によりそれよりも少ない容量に制限される。たとえば32ビット Linuxにおいては、最大16TiB

タグ: , , ,

4つの技術的バックアップの課題とその解決方法

投稿日: 2021年7月6日 クライム
ディザスタ・リカバリ

1. バックアップの破損

バックアップの破損は、バックアップデータを失う最も頻繁な原因ではないかもしれませんが、最も恐ろしい原因の一つであることは間違いありません。バックアップがストレージに正常にアップロードされたと報告されても、いざ復旧しようとするとデータが破損していたという状況は想像できます。

なぜこのような事態になるのでしょうか？それは、適切な復旧テストを行わないと、データが復旧できるかどうかわからないからです。バックアップを管理するIT担当者は、データの一貫性を頻繁にチェックしてリカバリーテストを行うか、データが破損している可能性があることを認識する必要があります。

しかし、データが破損する典型的な理由とは何でしょうか？ここでは、最も一般的なケースをご紹介します。

●ランサムウェア：現代の暗号ロッカーは、バックアップストレージやバックアップデータを確認して、それを暗号化します。
●バックアップメディアの破損：一般的に、これはオンプレミスのバックアップメ・ディアで起こります。例えば、ユーザがRAIDアレイのドライブの1つが故障したことに気づかず、一方ストレージはまだ安全ですが、災害に一歩近づいてしまうことになります。
●バックアップソリューションの失敗：今日では、Veeam社などの定評のあるバックアップベンダーが、実証済みで、検証済みのバックアップソリューションを提供しており、データを安全にストレージに移すことができます。しかし、時代遅れのバックアップソリューションやフリーウェアのバックアップソリューションを使用した場合、ストレージ上のデータの一部が不整合となり、少なくとも一部は復旧できない可能性があります。

では、破損したバックアップから身を守るにはどうすればよいのでしょうか？まず第一に、安定した実績のある最新のバックアップソリューションを採用する必要があります。バックアップソリューションの中には、自動でデータの一貫性をチェックする機能を備えた製品もあります。

次に、データを取り戻せるかどうかを確認するために、時々バックアップの復旧性をテストすることも重要です。

2. バックアップの消失または失敗

バックアップに問題はないと思っていても、単に破損しているだけではなく、完全に存在しないことがあります。これは、システム管理者が、スケジュールを設定するのではなく、自分の記憶を頼りにバックアップを開始した場合によく起こります。

バックアップを失う2つ目の理由は、管理者がバックアップの問題に関するアラートを設定することを忘れているか、その方法を知らないことです。

そこで、バックアップを完全に失わないようにするためには、次のようにします。

●自動化されたスケジュールを作成する
●バックアップが中断されないようにする。
●バックアップが完了しなかった場合の通知を設定する。

3. バックアップに時間がかかる

バックアップの技術的な問題としては、バックアップが完了するまでに時間がかかることがあります。

バックアップに時間がかかる主な理由は次のとおりです。

●インターネットの接続速度が遅い：ネットワークのパフォーマンスに問題がある。ここでは、会社の業務に影響を与えることなく、可能な限り最大のネットワークスループットを使用できるような適切な時間と設定を見つける必要があります。どうしてもアップロード速度を上げることができない場合は、バックアップデータの優先順位を考え、どのミッションクリティカルなデータを最初にアップロードするかを選択する必要があります。
●バックアップしたコンピュータの性能が低い：バックアップしようとしているコンピュータが与えられた時間内にタスクで過負荷になっている場合、バックアップ中にパフォーマンスの問題が発生したり、コンピュータ全体のダウンタイムが発生したりすることがあります。そのため、バックアップを実行する時間帯を選択する際には、ピーク時の作業負荷を確認し、通常のコンピュータ操作を妨げないようにする必要があります。
●バックアップタイプの選択を誤っている：バックアップにはさまざまなタイプがあります。ファイルレベルのバックアップに適しており、1つのファイルでも問題なく動作するものもあれば、マシンや選択したパーティションのフルコピーをストレージにアップロードするものもあります。そのため、与えられたデータセットに最も適したバックアップタイプを選択する必要があります。

4. バックアップにアクセスできない

最後に意外なことですが、バックアップストレージやバックアップメディアにアクセスできなくなり、災害時に貴重な時間を失ってしまうことがあります。アクセスできなくなる主な理由はいくつかあります。

●認証情報を忘れた、または紛失した：何よりもまず、パスワードを安全に保管し、アクセスできる場所に1つだけ置いておくべきです。また、管理用の認証情報を共有しないようにし、パスワードをローテーションする際には（漏洩していない限り推奨されませんが）、新しいデータでパスワード管理システムを更新することを忘れないでください。

●侵害を受けた認証情報： 悪意のある者がバックアップストレージ上の認証情報を変更することができるため、バックアップにアクセスしてデータを回復することができなくなります。これが、パスワードを安全に管理し、バックアップ・メディアやストレージへのアクセスログに不審な動きがないかを監視し、ユーザーがバックアップストレージにアクセスできないように制限すべき2つ目の理由です。アクセスできる人が少なければ少ないほど、上手に攻撃される可能性は小さくなります。

リスクを分散させる

最後にもう一つ、実用的なアドバイスがあります。バックアップの技術的なリスクを分散させるために、3-2-1のバックアップ戦略を貫くべきです。

タグ: ,

AWS利用組織を改善する4つの便利なサービス

投稿日: 2021年6月29日 クライム
AWS

AWS S3 Storage Lens

ストレージは、クラウドで最も利用されているサービスの一つであり、コンピューティングパワーに匹敵するものです。。しかし、適切なS3ストレージツールを使用しても、データをS3バケットにダンプするだけではなく、データを保存するための方法があります。より多くのオブジェクトを保存したり、クラウドのストレージ要件が変化したりすると、適切なデータ管理から遠ざかる傾向があります。つまり、サブフォルダの構造や命名規則性などが理想的でなくなる可能性があります。

つまり、複雑さとストレージの増加に伴い、手に負えなくなり、機能的ではあっても、非常に混乱したストレージ・ソリューションになってしまうのです。これでは、適切なストレージ階ティアを利用していないため、結果的に過剰なストレージコストが発生してしまいます。例えば、あまり使わないデータをAWS Glacierのようなコールド・ストレージや、少なくともInfrequent Access S3ティア(層）に移す代わりに、追加のメリットがないのにコストがかかるStandardティアを過剰に利用している可能性があります。

整理整頓する

このようなシナリオに対処するために、AWSはクラウドストレージの分析を支援する機能であるS3 Storage Lensをリリースしました。S3 Storage Lensは、AWS Organizationsと統合することで、保存されているデータを様々な指標（約30種類）やトレンドを用いて、組織全体で可視化します。これにより、コストの非効率性や異常性を発見することができます。

特に、AWSクラウドにあまり精通していない場合や、専任のチームを持っていない場合には、S3 Storage Lensは推奨事項も提供してくれるので、非常に助かります。また、ユーザ自身で計算したい場合は、詳細なダッシュボードが用意されており、様々なパラメータ（リージョン、バケット、アカウントなど）に基づいてデータを集約することができます。このデータは、さらに分析するためにインジェストしたい場合は、生のフォーマットでS3バケットにも保存されます。

S3 Storage Lensは、15種類のメトリクスを含むダッシュボードを無料で提供しています。アドバンスド・ティアにアップグレードすると、30種類以上の使用状況やアクティビティのメトリクス、コンテクストに基づいた推奨、プレフィックスのアグリゲーションなど、高度なメトリクスや推奨を受けることができますが、これには月に100万オブジェクトを監視するごとに0.20ドルかかります。また、アドバンスド・ティアには、15ヶ月間のデータ保持、アクティビティ・メトリクス、プレフィックス・レベルのアグリゲーションが含まれます。

AWS Security Hub

AWSでは、潜在的な脅威や設定ミスを警告したり、単に指標の望ましい閾値を超えたことを通知したりするために、多数のさまざまなツールや機能を提供しています（例：本番サーバのCPU使用率が高い）。

しかし、問題はこれらのアラートの多くが各サービスに分散していることです。つまり、Systems Manager、GuardDuty、Firewall Manager、Amazon Inspectorなどがあり、それぞれが独自のアラートのセットを持っているのです。

これらすべての間を絶えず行き来するのを避けるために、AWSはAWS Security Hub（セキュリティ・ハブ）を提供しています。これは、セキュリティ・アラートやその他の発見事項を整理し、集約し、優先順位をつけることができる集中的な場所です。AWS Security Hubは、様々な自動化されたセキュリティ・チェックにより、お客様のクラウド環境を監視します。さらに、Amazon Detectiveを使用してこれらの発見事項を調査し、CloudWatchのイベントルールに依存して、様々なインシデント管理ツールに発見事項を送信することができます。

AWS Security Hubには、さらに「Security Checks」と「Finding Ingestion Events」があります。前者は、あらかじめパッケージ化されたセキュリティ基準（PCI DSSやCISなど）を提供するもので、Security HubはAWS Configを活用して設定を記録する。これらのセキュリティチェックは、最初の100,000チェック/アカウント/リージョン/月までは1チェックあたり0.0010ドルで、使えば使うほどAWSの価格が下がっていく仕組みになっています。

一方、Security HubのSecurity Checksに連動するFinding Ingestion Eventsは完全に無料で、お客様が既に利用している様々なAWSサービスからAWS Security Hubがデータを取り込むだけで機能します。

AWS License Manager

特に大企業では、Oracle、SAP、IBM、Microsoftなど、複数のベンダーのライセンスを持っていることが多く、ソフトウェアのライセンス管理は面倒な作業となります。これらのライセンスを管理すること自体が問題ですが、ライセンス契約の条項に違反していないかどうかも確認する必要があります。AWS License Managerを使えば、様々な契約の条件を再現するカスタマイズされたライセンスルールが得られ、ライセンス違反を回避することができます。

AWS License Managerは、潜在的な違反について通知するだけでなく、例えば、ライセンスの範囲外のインスタンスを起動することを防ぎます。基本的に、AWS License Managerはコンプライアンス違反の可能性を大幅に低減し、それに伴う追加コストを削減します。これは、今日、過大請求が珍しくない中での嬉しいメリットです。また、スプレッドシートやカスタム通知からマネージドソリューションに移行することで、時間を大幅に節約することができます。

AWS License Managerは追加費用なしで利用できるため、様々なベンダーのライセンスに依存しているクラウド環境では必ず利用すべき機能です。

AWS Audit Manager

監査は、クラウドにおけるセキュリティとコンプライアンスの確保に重要な役割を果たします。しかし、監査は疲れる作業でもあり、他の場所でより良く使える時間を奪ってしまいます。だからこそ、AWS Audit Managerのような機能を検討する必要があるのです。AWS Audit Managerは、クラウドの利用状況を継続的に監査することで、リスク評価とコンプライアンスを大幅に簡素化することができます。これにより、少ない労力で業界標準に準拠していることを確認することができます。

AWS Audit Managerは完全に自動化されており、組織全体（必要に応じて1つまたは複数のアカウント）にわたって証明を収集することで機能します。これは、監査プロセスが追跡困難なレベルまでスケールアップする可能性がある大規模なクラウド環境では特に重要です。Audit Managerは、これらのデータを使用して、AWSリソースを様々な業界標準や規制（GDPR、PCI DSS、CISなど）にマッピングしてレポートを作成します。もちろん、これはお客様の特定のニーズに合わせてカスタマイズすることができます。最終的には、このレポートによって、自社の活動やポリシーなどがあるべき姿になっているかどうかを簡単に評価することができます。AWS Audit Managerは、社内のリスク評価やクラウド上での監査の自動化を必要とするユーザや、ステークホルダー（株主）への報告の準備をされているユーザにとって、最適なツールです。

Audit Managerは、各リソースの評価ごとに課金され、最低料金や前払いの必要はありません。各リソースアセスメントは、ユーザアクティビティ（AWS CloudTrailから収集）、コンプライアンスチェックの結果（AWS Security HubまたはAWS Configから）、リソース構成のEBSスナップショット（AWSから直接キャプチャ）など、1セットの証明を生成します。コストは、アカウントごと、リージョンごとに、Audit Managerのリソースアセスメント1,000件につき1.25ドルです。

タグ: , , ,

AWS Storage Gatewayを活用してAWS Hybrid Cloudデータを保護

投稿日: 2021年6月20日 クライム
AWS ディザスタ・リカバリ

AWS Hybrid Cloudのメリット

ハイブリッド・クラウドは両方の長所を備えているため、設計時に何をどこで使用するかを選択することができます。ハイブリッド・クラウドは、イノベーションの機会、柔軟性、そして俊敏性を提供します。環境やインフラの変更が求められるペースを考えると、これは非常に有効です。今日のパブリッククラウドサービスが提供するプロビジョニングスピードに匹敵するデータセンターはありません。

さらに、AWSのハイブリッド・クラウドを利用すれば、ワークロードを分離したい場合にも役立ちます。例えば、コンプライアンス上の要件からオンプレミスのデータセンターを離れられない機密データを扱っている場合などです。それ以外のニーズについては、クラウドを利用して簡単にリソースを提供することができます。

ハイブリッド・クラウドは、AWSの移行プロジェクトにおいても非常に有益です。多くのインフラや大規模な環境を持たない小規模な企業やスタートアップ企業は、多くの場合、クラウドへの切り替えを迅速に行うことができます。大企業の場合にはこのプロセスには時間がかかります。ハイブリッド・クラウドを利用することで、ゆっくりと自分たちのペースで事業を拡大していくことができます。

このようなメリットには代償が伴います。多くのインフラを維持しなければならないため、余分な費用が発生する可能性があります。また、ハイブリッド・クラウドの利用に伴い、セキュリティ上の課題が増えることも難点です。ハイブリッド・クラウドを利用すると、ビジネス環境の複雑性が飛躍的に高まり、ミスが発生する可能性が高くなります。認証や承認から、データをオンプレミスのサーバーからクラウド（ネットワークはインターネットにまたがる）に送信するまで、各ステップで適切な設定が必要になります。また、従業員がAWSに慣れ親しむためのトレーニングも必要かもしれません。従業員の知識にギャップがあると、将来的にコストのかかるミスにつながる可能性もあります。

AWS Storage Gatewayとは？

では、AWS Storage Gatewayとは何なのか、そしてそれはユーザのビジネスにどのように役立つのか。Storage Gatewayは、オンプレミス環境からAWSの無制限のストレージ容量にアクセスできるハイブリッドクラウドサービスです。以下の3種類のゲートウェイが用意されています。それぞれが特定のユースケースのために設計されており、オンプレミスのサーバーとAWSのクラウドをシームレスに接続します。

Volume Gatewaysは、クラウド上のブロックストレージをiSCSIボリュームとしてオンプレミスのアプリケーションに提供します。Volume Gatewaysは、バックアップやAWSのディザスタリカバリ、アプリケーションデータのクラウドへの移行に最適で、ローカルキャッシュやオンプレミスのフルボリュームを提供するとともに、クラウド上にデータのフルコピーを保持します。

File Gatewaysは、オンプレミスのリソースをAWS S3に直接接続することができ、アクセスにはNFSまたはSMBプロトコルを使用します。クラウドでのバックアップが必要な場合、クラウドのコンテンツリポジトリを管理したい場合、データ処理にAWSベースのサービスを使用したい場合など、File Gatewaysはユーザのタスクを簡素化します。

Tape Gatewaysは、既存のレガシーバックアップソリューションに、業界標準のiSCSIベースの仮想テープライブラリ(VTL)を導入することで、すべてのバックアップをS3に直接オフロードすることができます。オンプレミスのバックアップ設定に変更を加える必要はなく、すべてのバックアップは後にGlacierやGlacier Deep Archiveのような長期コールドストレージソリューションに転送することができます。

AWS Backup for Storage Gateway

データのバックアップは非常に重要であり、このニーズをサポートするAWSサービスがあると非常に便利です。ここまでは、AWS Backupを使って他のクラウドベースのリソースをバックアップする方法を紹介してきましたが、今回は同じサービスを使ってStorage Gatewayのボリュームをバックアップする方法を紹介します。

他のクラウドベースのリソースをバックアップする場合と同様に、Storage Gatewayのボリュームをバックアップする前に、いくつかのステップが必要です。まず始めに、まだ作成していない場合は新しいボールト(Vault)を作成します。デフォルトのボールトを使用することもできますが、適切に設計されたバックアッププランの一環として、独自のボールトを作成した方が良いでしょう。特に、複数のリソースを使用していて、論理的に分離したい場合はなおさらです。

これが完了したら、AWS Storage Gatewayのバックアップを開始できます。カスタムバックアッププランを作成し、バックアップしたいリソース（ここではStorage Gatewayボリューム）を割り当てる方法と、オンデマンドでバックアップを作成する方法があります。前回の記事ではバックアッププランの作成方法を紹介しましたが、今回はオンデマンド・バックアップ・オプションの使い方を説明します。

AWS Backup Serviceで、「Create an on-demand backup」をクリックします。

次に、リソースタイプとしてStorage Gatewayを選択し、バックアップしたいボリュームを選択します。ここでは、バックアップウィンドウとバックアップのライフサイクルをカスタマイズし、例としてここでは4週間の期限を設定します。バックアップボールトとIAMロールを選択して（どちらもデフォルト設定のままでOK）、「Create on-demand backup 」をクリックします。

画面の下半分には、バックアップジョブの進捗状況が表示されます。

ジョブが完了すると、ボリュームがバックアップされます。

N2WS Backup and Recoveryを最大活用

AWS Backupはリソースをバックアップするのに適したツールですが、限界もあります。現時点では、AWS Backupは一部のサービスにしか対応しておらず（VPC、Aurora、RedShiftには対応していません）、また、1つのAWSアカウントでしか動作しません。最近では、ほとんどの企業が複数のクラウド・アカウントを所有しており、アカウント間でのバックアップ機能がないことは大きなデメリットとなっている。このような企業の多くは、セキュリティを強化するとともに、すべてのデータを一元的にバックアップするソリューションを求めています。

N2WS Backup and Recoveryはこれを実現します。N2WS Backup and Recoveryは、クラウドネイティブな製品であり、お客様のすべてのAWSアカウントと連携して、迅速かつ簡単にバックアップを行うことができ、数回クリックするだけで、あらゆるリージョンやAWSアカウント内のデータを復元することができます。また、N2WS Backup and Recoveryは、ネットワークインフラを迅速に復旧するためのVPC Capture and Clone、S3へのダイレクトバックアップ（バックアップデータを最大40%節約することができます）、強化されたファイルレベルの復旧、詳細なレポートなどの追加機能を提供します。

タグ: ,

クラウド・ストレージ・プロバイダーを選ぶための3ステップ

投稿日: 2021年6月13日 クライム
AWS Azure クラウド・仮想インフラ ディザスタ・リカバリ

企業のあらゆるニーズに対応するクラウドストレージ・ソリューションはありません。データのバックアップを保存すると同時に、ファイル共有やコラボレーションサービスとして利用できるソリューションはありません。確かに、Microsoft OneDriveやDropbox for Businessをバックアップ用に使用したり、AWSのAmazon S3をファイル共有用に設定したりするかもしれませんが、ほとんどの場合、非効率的で高価で安全性の低いソリューションになってしまいます。ここでは、ユーザ固有のニーズに基づいて、クラウド・ストレージ・プロバイダーをどのように選択すべきかを説明します。

ステップ1. 良いクラウド・ストレージ・プロバイダーのチェックリストを作る

現代のクラウド・ストレージ・プロバイダーが備えるべき特徴的な機能や特性には、以下のようなものがあります。

●徹底したセキュリティ管理：データの漏洩は常に起こっています。そして、その最も一般的な理由は、セキュリティ管理の設定が弱く、セキュリティ・ツールが不足していることです。同時に、データの紛失や漏洩は、ダウンタイムや金銭的な損失、さらにはコンプライアンスの基で業務を行っている場合には訴訟に発展するなど、大惨事となります。そのため、クラウド・ストレージ・プロバイダーは、きめ細かなアカウント設定、データ暗号化ツール、多要素認証、データの堅牢な物理的セキュリティなど、あらゆる種類のアイデンティティおよびアクセス管理ツールを提供する必要があります。

●競争力のある、明確な価格設定：クラウドプロバイダーの中には、ストレージの提案をあまり気にしないところもある。例えば、ソリューション・スタックの中で他のサービスに注力しているところなどです。しかし、最大手のクラウド・ストレージ・プロバイダーは、価格や機能セットの面で継続的な競争を行っており、現在、市場には素晴らしいソリューションが溢れています。

●充実したサポート体制： 大切なデータを物理的にアクセスできないストレージに保存しようとしているのですから、何か問題が発生したときに助けや相談が得られるかどうかを確認しなければなりません。選ぼうとするストレージプロバイダーが有料のサポートオプションを持っているかどうか、24時間365日要求に答えてくれるかどうかを確認するとともに、試用期間中にサポートに連絡してみて、その対応力をチェックしてみましょう。

●評判：安価な価格設定で、Webページにはたくさんのおしゃれな言葉が並んでいて、評判の悪い、名もなきクラウド・ストレージ・プロバイダーには手を出さないほうがいい。この点については、ブログの後半で詳しく説明します。

ステップ2. ニーズの定義

データストレージソリューションは、さまざまなニーズを満たすように設計されています。そのため、まず自社でどのようなタイプのソリューションが必要なのかを定義してから、正確なベンダーを探し始める必要があります。

バックアップとファイル共有

データストレージの導入で最もポピュラーなのは、バックアップストレージと、ファイル共有・コラボレーションの2つです。このようなクラウドストレージ・ソリューションは、価格、機能セット、UIなどの点で異なる。あらゆる部分で違いがある。

バックアップ用のクラウドストレージを選択する場合、一般的に優れたユーザーインターフェースは必要ありませんが、大量のデータを保存するための低価格、優れたAPI、クラウドストレージサービスに統合されたデータバックアップソリューションは必要です。

一方、ファイル共有ソリューションでは、エンドユーザーが多くの作業を行うため、まず明確で分かりやすいユーザーインターフェースが必要です。また、きめ細かなアクセス権限の設定や、ストレージ内のアクティビティを監視する機能も必要です。最後に、ファイル共有型クラウドストレージサービスの中には、ドキュメント、スプレッドシート、プレゼンテーションの共同作業を可能にするものがあり、企業内のエンドユーザーの全体的な効率を高めます。

コンプライアンス

コンプライアンスの下で業務を行う場合、データの転送、共有、保存には細心の注意を払う必要があります。そのためには、コンプライアンス上の問題を解決するための認定を受けたクラウドストレージ・ソリューションを利用する必要があります。また、データを完全に保存しておく必要がある場合は、Write Once Read Many（WORM）タイプのストレージソリューションを提供するクラウドストレージベンダーをチェックしてください。WORM型クラウドストレージでは、一度アップロードされたデータは一切変更できません。

初期のデータ転送

クラウドストレージに転送しなければならないデータがすでに何テラバイトもあり、その後も少しずつしか転送しない場合、インターネット経由でデータを転送するのに数ヶ月を費やすことになる。あるいは、AWS Amazon SnowballやBackblaze B2 Fireballのようなストレージアプライアンス経由で初期データをアップロードできるストレージソリューションを見つけることもできます。

これらのソリューションは次のような仕組みになっています。クラウド・ストレージ・プロバイダーからアプライアンスが送られてきて、ユーザはそこにデータをアップロードして送り返します。アプライアンスがストレージプロバイダーの施設に到着すると、プロバイダーはローカルネットワークを介してデータをデータセンターにアップロードします。これが完了すると、データセットが利用可能になります。

ステップ3. クラウド・ストレージ・プロバイダーを選ぶ

希望のリストができたら、次は自分のニーズに合ったクラウド・ストレージ・プロバイダーを探しましょう。ここでの唯一のアドバイスは、名前と評判のある、すでに確立されたプロバイダーを探すことです。その理由は以下の通りです。

データストレージは、非常にコストのかかるビジネスです。地理的に分散した要塞化されたデータセンターの中に防弾仕様のインフラを構築し、エンジニアや一流の開発者を自由に使えるようにしなければならない。そのためには莫大なコストがかかり、名もないストレージプロバイダーがデータの安全性を保証してくれるわけではありません。

また、老舗の大手クラウド事業者がしのぎを削っていますので、自分のニーズと価格に合わせて選ぶことができるでしょう。

クラウドストレージに強いBDRベンダー

バックアップのためのクラウド・ストレージ・プロバイダーを見つけるだけでは十分ではありません。ほとんどの場合、クラウドストレー・ソリューションには、ユーザーインターフェースやネイティブなバックアップソリューションがありません。そのため、選択したクラウドストレージに統合された、信頼できて使いやすいバックアップおよびディザスタリカバリ（BDR)・ソリューションのプロバイダーを見つける必要があります。

タグ: